Squarespace Video Size Limit: 500 MB per File, 30 Minutes Total

A 900 MB client reel won't upload into a Squarespace video block. You compress it to 400 MB, it uploads fine, and playback looks soft and blocky next to your export. Then the next video fails with no size problem at all.

Quick answer: The Squarespace video size limit is 500 MB per uploaded file, and every Squarespace site also has a separate 30 minute cap on total native video duration across all pages. Squarespace re-encodes whatever you upload, so the job is handing it a clean H.264 MP4 under 500 MB: compute the bitrate as target_MB × 8192 ÷ duration_in_seconds, subtract your audio bitrate, and encode with -profile:v high -movflags +faststart. To do that for a folder of client videos without installing FFmpeg, send each file to FFmpeg Micro as one API call.

Squarespace caps video two ways, and only one of them is about file size

Squarespace enforces two unrelated limits on native video: 500 MB per file, and 30 minutes of total duration counted across every video in your library, including ones you never put on a page.

Most compression advice treats this as a file size problem. On a real client site it usually isn't. A 40 second hero loop has a 500 MB budget, roughly 100 Mbps, and nothing you export from Premiere or Resolve comes near that. The limit that bites is the 30 minute allowance, and no encoder setting makes a video shorter.

One more number trips people up: the asset manager behind Custom CSS caps files at 20 MB. Native video goes through a video block, not that file manager.

Why a Squarespace video upload fails when the file is under 500 MB

A Squarespace video upload can fail for at least four reasons unrelated to the 500 MB cap. The one people miss is the duration allowance: if the library already holds 28 minutes, a 4 minute clip is rejected however small you made it.

The other three are encode problems. Squarespace wants MP4 or MOV with H.264 video and AAC audio, so an MKV, a WebM, or a ProRes master in a MOV wrapper is a coin flip. Recordings from OBS and QuickTime often carry variable frame rate, which survives upload but plays back with drifting audio sync. And a 480 MB browser upload over 10 Mbps takes about seven minutes, long enough that a sleeping laptop kills it silently.

Check the file before you spend the upload:

ffprobe -v error -show_entries format=duration,size,bit_rate \
  -show_entries stream=codec_name,width,height,r_frame_rate,avg_frame_rate \
  -of default=noprint_wrappers=1 input.mov

That gives you the container, both codecs, the real duration, and whether the frame rate is variable. If r_frame_rate and avg_frame_rate disagree by more than a hair, force constant frame rate. The same inspection runs as one request through the FFprobe API when the file lives in a bucket.

The bitrate math that hits a target file size

Hitting a file size target is arithmetic, not trial and error. A megabyte is 8,192 kilobits, so the bitrate you can afford is target_MB × 8192 ÷ duration_seconds, minus audio.

Target 450 MB, not 500 MB. The extra 50 MB absorbs container overhead and the few percent single-pass x264 overshoots by. For a 12 minute video: 450 × 8192 ÷ 720 = 5,120 kbps total, minus 128 kbps for stereo AAC, so 4,992 kbps of video. Round down to 4900k.

The 450 MB budget buys this much at common durations, before subtracting audio:

The right column matters. Past about 8 Mbps for 1080p web delivery you're shipping bits Squarespace throws away in its re-encode, so don't fill the envelope just because it's there. Only past 15 minutes does the cap force real quality decisions, and that's where the 30 minute budget becomes the bigger problem. The same arithmetic drives compressing video for Discord's tier caps; only the target number changes.

A web delivery preset Squarespace can re-encode without making it worse

Squarespace transcodes your upload into its own playback renditions, so your file is a mezzanine, not what visitors watch. Give it clean, artifact-free frames at a modest bitrate, because blocking or banding you introduce gets amplified by that second encode.

Two-pass x264 gives you predictable size and better bit allocation on the same budget:

# Pass 1: analysis only, no audio, discard the output
ffmpeg -y -i input.mov -c:v libx264 -profile:v high -level 4.1 -preset slow \
  -b:v 4900k -pix_fmt yuv420p -vf "scale=-2:'min(1080,ih)'" -r 30 \
  -an -pass 1 -f mp4 /dev/null

# Pass 2: the real encode
ffmpeg -i input.mov -c:v libx264 -profile:v high -level 4.1 -preset slow \
  -b:v 4900k -maxrate 5400k -bufsize 9800k -pix_fmt yuv420p \
  -vf "scale=-2:'min(1080,ih)'" -r 30 \
  -c:a aac -b:a 128k -ac 2 -ar 48000 \
  -movflags +faststart output.mp4

On Windows, pass 1 writes to NUL instead of /dev/null. The scale expression caps height at 1080 without upscaling smaller sources, and -2 keeps the width even, which H.264 requires. -pix_fmt yuv420p matters for 10-bit or 4:2:2 sources, because browsers won't decode those. -movflags +faststart moves the moov atom to the front so playback starts before the file finishes downloading.

-r 30 is deliberate. A 60 fps source at 20 minutes needs twice the bitrate to look the same, and on a marketing page nobody notices. Spend the bits on detail instead. Same tradeoff that makes platform spec sheets less useful than the encode itself.

Budgeting 30 minutes across a client's library

The 30 minute allowance is the limit you can't compress your way out of, so add up the durations of everything the client wants natively hosted before you touch an encoder.

A 40 second hero loop, six 90 second product demos, and three 2 minute testimonials come to 940 seconds, about 15.7 minutes. Add an 18 minute recorded webinar and the total hits 33.7 minutes, over the cap, and the webinar is the only thing that can give. It goes to a YouTube or Vimeo embed, which costs nothing against the allowance.

Deleting a video reclaims its minutes, so an abandoned first cut is duration doing nothing. The allowance counts duration, not size: a 29 minute video compressed to 60 MB eats the whole budget, while a 400 MB 90 second clip costs 1.5 minutes.

Batch encoding a folder of client assets

An agency prepping a handoff encodes a folder, not a file, and every file needs its own bitrate because every file has its own duration. A loop over ffprobe and ffmpeg handles it:

#!/usr/bin/env bash
TARGET_MB=450
AUDIO_K=128
mkdir -p out
for f in ./client-assets/*.{mov,mp4,m4v}; do
  [ -e "$f" ] || continue
  dur=$(ffprobe -v error -show_entries format=duration -of csv=p=0 "$f")
  v=$(python3 -c "print(min(int($TARGET_MB*8192/$dur) - $AUDIO_K, 8000))")
  ffmpeg -y -i "$f" -c:v libx264 -profile:v high -preset slow \
    -b:v ${v}k -maxrate $((v*11/10))k -bufsize $((v*2))k \
    -pix_fmt yuv420p -vf "scale=-2:'min(1080,ih)'" -r 30 \
    -c:a aac -b:a ${AUDIO_K}k -ac 2 -ar 48000 \
    -movflags +faststart "out/$(basename "${f%.*}").mp4"
done

Single pass with -b:v plus -maxrate lands within three or four percent of target, which is why 450 MB has headroom. Switch to two-pass for anything close to 500 MB.

That script still needs FFmpeg installed, the client's 40 GB of camera masters copied locally, and an hour of your laptop's fans. The same work runs as one API call per file through the FFmpeg Micro API: request a presigned upload URL, PUT the file, submit the transcode, poll, download. Jobs run in parallel, and billing is metered per second of input, so that 940 second library costs 94 of the 200 tokens a free account starts with. The same pattern drives cutting one product video into four platform variants.

Input size has a ceiling on our side too: 100 MB per file on the free tier, 1,024 MB on Starter at $19.99 a month, 2,048 MB on Pro. A 4 GB ProRes master exceeds all three, so downscale that one locally first.

When to stop fighting the limit

Encoding harder is sometimes the wrong move. A single video over roughly 15 minutes, a library near 30 minutes, or a client who adds video monthly all point the same way: stop using native Squarespace video for long-form, and embed it from a video host.

Native video blocks are right for short, muted, decorative clips and demos under two minutes. They're wrong for webinars, course lessons, and anything needing adaptive bitrate so a viewer on mobile data doesn't buffer. A dedicated video host with its own player and CDN is the tool there, and the allowance stays free for clips that belong on-page.

FFmpeg Micro processes video, it doesn't host or stream it. You get a finished MP4 back and still upload it to Squarespace or put it behind your own player.

Common pitfalls

Uploading your ProRes or high-bitrate master fails twice over: it's almost certainly past 500 MB, and Squarespace re-encodes it anyway, so the extra bits buy nothing.

Over-compressing is the subtler problem. Squeeze a 20 minute video to 80 MB and you get visible blocking, which Squarespace's re-encode treats as detail worth preserving. Generation loss compounds.

Leaving old uploads in the library quietly spends the 30 minute budget, and forgetting -movflags +faststart delays playback while the player hunts for the index at the end of the file. Audit the library before you conclude an upload was rejected for size, because the error doesn't always distinguish the two causes.

FAQ

Can I increase the Squarespace video size limit?

The Squarespace video size limit can't be raised by the site owner. 500 MB per file and 30 minutes of total duration are fixed, so your levers are compressing each file to fit, deleting unused videos, and moving long-form to an external embed.

Why is my Squarespace video not uploading even though it's small?

A small file that won't upload usually means the site has used up its 30 minute video allowance, or the file isn't H.264 with AAC audio in an MP4 or MOV container. Run ffprobe on it to confirm both codecs and the duration before you retry.

Does Squarespace compress videos after upload?

Squarespace re-encodes every native video upload into its own playback renditions, which is why your file looks softer on the page than in your editor. You don't control those settings, so upload a clean H.264 MP4 at a moderate bitrate instead of a large master.

What video settings should I use for Squarespace?

The settings that work for Squarespace native video are H.264 high profile in MP4, 1080p, 30 fps, AAC stereo at 128 kbps and 48 kHz, faststart on, and a video bitrate picked from the duration so the file lands near 450 MB. Under five minutes, cap it at 8000 kbps.

How many videos fit in Squarespace's 30 minute limit?

The 30 minute Squarespace video allowance holds about 45 clips of 40 seconds, or 20 clips of 90 seconds, or a single 30 minute recording and nothing else. Duration is what counts, not file size, so a heavily compressed long video costs the same as an uncompressed one.

If you'd rather not install FFmpeg on the machine that also runs the agency, you can batch-compress a folder to a target size through the API on the free tier: 200 tokens, about 33 minutes of video, no card. Sign up free and point it at the first file.