---
title: Content types and limits
description: The accepted file types, the size caps at every layer, and how a bad upload fails.
---

# Content types and limits

## Accepted file types

sherserve validates an upload's content type from its filename's
extension alone — never sniffed from the file's own bytes — against a
fixed allow-list:

- **Images**: `png`, `jpg`/`jpeg`, `gif`, `webp`, `svg`, `avif`
- **Video**: `mp4`, `webm`, `mov`, `m4v`
- **Audio**: `mp3`, `wav`, `ogg`
- **Documents**: `pdf`, `txt`, `csv`, `json`, `md`
- **Archives**: `zip`, `gz`, `tar`

An extension that isn't on this list — or a filename with no extension
at all — is a clean `415`, naming the path it checked so the error reads
as "this file's type isn't supported" rather than as if some other
field were rejected.

## Extension inferred from content type

`store_upload_content` (the hosted-MCP upload tool — see
[uploading](/sherserve/uploading)) has no local file to read an
extension from. If its `path` hint has no extension, the tool infers
one client-side from the required `contentType` argument before
uploading — `image/png` becomes `.png`, and so on for the common image,
text, and document types. If neither the filename nor `contentType`
supplies a usable extension, the tool fails before making a network
call at all, rather than letting the platform's own `415` surface
first.

## Size limits

The reverse proxy in front of the platform accepts request bodies up to
**520 MB** — large enough to cover every upload path on the platform,
sherserve's included. Above the platform's own per-object cap of
**500 MB**, the upload route itself rejects the file with a clean `413`
before it's ever written to storage. In practice: a large upload either
succeeds in full or fails cleanly at a known size — it never silently
truncates partway through.

## Next

[The f. url](/sherserve/the-f-url).