begin, from the name, type and size the browser declared, before the before-upload callback runs. A refused file leaves nothing behind: no presigned URL, no row, no multipart upload.
Omitting constraints accepts any type at any size. The option names in each SDK: TypeScript, Python, Go.
In the constraints document served to the browser they are maxSize and contentTypes.
Max size
MB uses powers of 1,000; MiB uses powers of 1,024. Units ignore case. To accept a 32 MiB file, set it to "32MiB" or 33554432. "32mb" means 32,000,000 bytes and is too small for that file.
Refusal messages display decimal byte units, or exact bytes when the file and the limit would round to the same text:
int64 and cannot be unparseable; blob.ParseSize reads one from configuration.
Content types
type/subtype, or one of three wildcards: image/*, video/* and audio/*.
Anything else throws invalid_content_type_pattern: */*, text/*, and strings that are not a media type (png, image/, /png). An empty list throws too; omit the option to accept anything.
What the wildcards expand to
image/* deliberately does not include image/svg+xml. An SVG can contain script, so allow it explicitly by listing 'image/svg+xml'.Aliases
Browsers and operating systems send several spellings for some types. Both the declared type and your list are canonicalized before comparison, so a list of['image/jpg'] accepts a file declared image/jpeg, and the reverse. Parameters are stripped, so image/png; charset=binary is image/png.
Alias table
Alias table
Byte sniffing
A route with content types checks more than the declared type. The browser sends the file’s leading bytes with thebegin request, so a mislabelled file is refused before the upload rather than after it. Two checks run:
- The declared type must be in the allow list. A
report.exedeclared asapplication/x-msdownloadis refused here. - The leading bytes must not clearly contradict the declared type. If the bytes prove nothing, the file passes.
.docx really is a zip, and so are .epub, .jar and .apk. Formats that share a signature, like mp4 and heic, or webm and mkv, never contradict a declaration. Neither does application/octet-stream.
This is a convenience, not a security control. The bytes never reach your server, so a client can send an honest sample and then upload something else. It is not malware scanning, and stored objects should still be treated as untrusted.
Per-route constraints
A route’s constraints override the handler’s key by key. A key the route does not mention is inherited. An explicit null (
None in Python) clears a key the handler set. In Go, where a zero value means inherit, an empty ContentTypes slice or MaxSize: blob.NoLimit clears it.
Narrowing per user
In the browser
GET on the upload route serves the constraints it enforces, cached for 60 seconds, so a deploy that changes a route’s limits reaches clients within a minute.
useUpload exposes two things from it. accept is contentTypes joined with commas, ready for an <input accept>. constraints is the served document itself, so a page can show the limit it enforces.
components/upload-button.tsx
status: 'error' and a BlobError with code too_large, so one error path renders both the client-side refusal and the server’s.
The size check is the only one that runs in the browser. The server is authoritative for everything else. If the constraints have not arrived yet, the file is simply sent and the route decides.
Error codes
A refusal here istoo_large, content_type_not_allowed, invalid_content_type_pattern or empty_body. It reaches the browser as a BlobError with that code intact, so switch on error.code rather than on status numbers. See Errors.
Server-side writes
put takes the same content types and max size options, with the same grammar, aliases and byte check, for bytes that pass through your own route. See Writing.