Squarespace 7.1 automatically serves WebP variants for images uploaded through the editor, with JPEG/PNG fallbacks for older browsers1. WebP typically achieves 25-35% better compression than JPEG at the same visual quality2. AVIF — the next-gen format with even better compression — is not currently supported across Squarespace as of Q2 2026, verified against Squarespace's own help documentation.
The lever you control is the source resolution. Squarespace's automatic WebP compression compounds with smaller source dimensions, so capping your hero uploads at 1920px wide cuts payload by 4-7x for typical photos.
§01Default
What Squarespace serves automatically
Three behaviours ship by default on Squarespace 7.1 for editor-uploaded images. (1) Auto-WebP conversion: any JPEG or PNG uploaded through Image Block, Gallery Block, or Commerce product images is served as WebP to browsers that support it. (2) Responsive srcset: multiple variants at different widths (typically 100w, 300w, 750w, 1500w, 2500w) are generated and served via the picture element. (3) Fallback: JPEG or PNG is served to older browsers that do not support WebP. All three behaviours are automatic — no setting, no toggle, no plugin.
The behaviour applies only to images uploaded through the Squarespace editor. CSS background-image URLs in Custom CSS are served as the original format, no conversion. Code Block embeds bypass Squarespace's image pipeline entirely. For everything in regular Image Blocks and Gallery Blocks, WebP is the default served format on every modern browser1.
WebP compression versus JPEG
25-35%
smaller files than JPEG at equivalent visual quality. Compression varies by image content.
AVIF is the next-generation image format with another 30-50% compression improvement over WebP. Browser support reached ~94% of global users by Q1 2026 per caniuse.com, which means most users could receive AVIF if the server supported it. The constraint on Squarespace is the platform: as of Q2 2026, Squarespace's image pipeline serves WebP and JPEG/PNG, not AVIF. There is no public timeline for AVIF support. The honest 2026 framing is: WebP is what you get; AVIF is what you might get later.
caniuse.com tracks AVIF browser support3 — major browsers (Chrome, Firefox, Safari, Edge) all support it in recent versions. The bottleneck is the server-side encoding pipeline. Squarespace's CDN does not currently encode AVIF variants, so even if your browser supports it, the served image is WebP.
§03Lever
The source-resolution lever
Squarespace's auto-WebP compression compounds with smaller source dimensions. A photo uploaded at 5,000px wide compresses to WebP at ~2-3MB. The same photo resized to 1920px wide before upload compresses to WebP at ~400-600KB. The visual result is identical at any normal viewport. The payload is 4-7x smaller. The implication: source-resolution capping is a larger optimisation than the WebP conversion itself.
The reason is that WebP compression is roughly proportional to source pixel count. Halving the dimensions of an image quarters the pixel count (because area scales with width × height), and a quartered pixel count is roughly a quartered compressed file size. Squarespace's auto-WebP does the same percentage compression on both — 5,000px and 1920px — but starts from very different baseline sizes.
textThe compression math — same photo, different uploads
# Source: 5000 × 3333 photo (16.6 megapixels)
JPEG source : ~6.0 MB
Squarespace WebP: ~2.4 MB (60% reduction)
# Same photo resized to 1920 × 1280 before upload (2.5 megapixels)
JPEG source : ~1.1 MB
Squarespace WebP: ~440 KB (60% reduction)
# Net effect: 5.4x smaller payload, same visual quality on common viewports
§04Caps
Source-dimension cap recommendations
Four caps cover almost every Squarespace use case. Full-bleed hero: 1920px wide. In-section images that span most of the column: 1200px wide. Small inline images (icons, thumbnails): 600px wide. Product images for ecommerce zoom: 2000px wide to support the zoom interaction. For retina displays, double the cap is overkill in 2026 — Squarespace's responsive srcset picks the right variant for the viewport, and the 1920px source still generates a sharp 1500w retina variant.
The cap pattern is intentionally conservative — you can always upload a larger source and adjust later, but capping at upload prevents the largest variant from being unnecessarily big. The LCP leaf covers the LCP-specific reasoning in detail, including the preload tag that pairs with the dimension cap.
§05Verify
Verify the WebP is actually serving
Two verification methods. (1) Open Chrome DevTools, Network tab, reload the page, filter by Img. Each image row shows the served Content-Type — image/webp confirms WebP is being served. (2) Run PageSpeed Insights and check the 'Serve images in next-gen formats' audit — it passes when WebP is serving. If the audit fails, the platform-level WebP behaviour has not been triggered, usually because the image is a CSS background or a Code Block embed rather than an Image Block.
The PageSpeed Insights4 diagnostic also estimates potential payload savings — a useful sanity check on whether your source images are oversized. A passing audit that still suggests savings of 200KB+ usually means the source resolutions are too large. The image-SEO hub covers the full image-SEO play; this leaf covers the format-and-size lever specifically.
