Running your own Telegram Bot API server does not "remove the 50 MB limit" — it replaces the default caps with two different rules pointing in two different directions. In the "Using a Local Bot API Server" section of the Bot API documentation, Telegram lists them as two separate bullet points: "Download files without a size limit." and "Upload files up to 2000 MB."
Those are not one rule stated twice. Downloads lose their ceiling entirely. Uploads get a new, higher, but still finite ceiling — and the figure Telegram prints is 2000 MB, not "2 GB".
Almost everything that ranks for this query — GitHub issues, developer blog posts, Docker Hub pages — compresses the change into a single sentence about the 50 MB limit going away. That is right about the direction and wrong about the shape.
The limits, at a glance
| Default server (api.telegram.org) | Local Bot API server | |
|---|---|---|
Downloading a file (getFile) | "bots can download files of up to 20MB in size" | "Download files without a size limit." |
| Uploading via multipart/form-data | "10 MB max size for photos, 50 MB for other files" | "Upload files up to 2000 MB." |
| Uploading by HTTP URL | "5 MB max size for photos and 20 MB max for other types of content" | Not broken out separately in the docs |
Resending by file_id | "There are no limits for files sent this way." | Not mentioned in the local-server feature list |
file_path after getFile | A download link, "valid for at least 1 hour" | "Receive the absolute local path as a value of the file_path field without the need to download the file after a getFile request." |
| Uploading from disk | Not listed | "Upload files using their local path and the file URI scheme." |
| Webhook URL | Not listed as a local-server feature | "Use an HTTP URL for the webhook." |
Two of those cells say "not mentioned" on purpose. Telegram's local-server section is a five-item list, and the items it does not contain are not commitments — do not assume the file_id shortcut or the URL-upload route behaves differently just because you moved the server.
Also keep the qualifier Telegram attaches to its own numbers. Alongside the default 50 MB send limits, the docs repeatedly add: "this limit may be changed in the future." Treat the table above as the current published state, not a constant.
The five things a local server changes
Verbatim, the complete list of what Telegram says your bot "will be able to" do:
- "Download files without a size limit."
- "Upload files up to 2000 MB."
- "Upload files using their local path and the file URI scheme."
- "Use an HTTP URL for the webhook."
- "Receive the absolute local path as a value of the file_path field without the need to download the file after a getFile request."
The server source code, per the same section, "is available at telegram-bot-api".
Why the download side is the one that usually hurts
On the default server, the receiving direction is the tighter of the two, and the gap is large.
getFile is documented as: "For the moment, bots can download files of up to 20MB in size." The File object repeats it — "The maximum file size to download is 20 MB". Meanwhile the same bot can send files of up to 50 MB through sendDocument, sendVideo, sendAudio and sendAnimation — each of those methods states the figure with the same hedge attached, "this limit may be changed in the future".
So a default-configured bot can push out a file more than twice the size of the largest one it can pull in. And the mismatch with human users is wider still: Telegram's user FAQ says people can "share an unlimited number of photos, videos and files (doc, zip, mp3, etc.) of up to 2 GB each", and "up to 2 GB in size each (or 4 GB with Premium)". A user drops a 2 GB video into a chat, your bot sees the message, and getFile will not hand it over.
The local server removes that wall from both ends at once. The cap goes away, and the retrieval mechanism changes: instead of a temporary HTTPS link that Telegram guarantees only "for at least 1 hour" (after which "a new one can be requested by calling getFile again"), file_path comes back as an absolute local path.
The upload side: 2000 MB is a ceiling, not "unlimited"
This is where the vague summaries mislead. "Upload files up to 2000 MB" is a bound. If your pipeline produces exports bigger than that, self-hosting the API server does not solve your problem.
Note also the unit. The Bot API says 2000 MB. The user-facing FAQ says 2 GB and 4 GB, and it gives no byte values behind those two strings. The one place Telegram publishes arithmetic is the MTProto client config, where the file-parts field is documented as "the maximum file size can be extrapolated by multiplying this value by 524288, the biggest possible chunk size" — an extrapolation on the MTProto side, not a byte figure behind the FAQ's "2 GB". So do not convert between the published strings, and check the official documentation rather than assuming 2000 MB sits above or below the 2 GB user limit.
The practical consequence: for anything that has to move regularly, the right fix is usually to make the file smaller rather than to raise the ceiling.
Try it right here
Runs in your browser. Your file is not uploaded anywhere.
This runs inside your browser tab — the file is read from disk, re-encoded locally, handed back, and nothing is uploaded to a server. For more control over bitrate and resolution than a preset gives you, compress video exposes the same engine with the knobs visible, and all Clapr tools lists the rest.
One more route worth knowing before you build anything: if the file is already on Telegram's servers, you do not need to move bytes at all. The docs are explicit — pass the file_id and "There are no limits for files sent this way." The catch is also documented: "It is not possible to change the file type when resending by file_id. I.e. a video can't be sent as a photo, a photo can't be sent as a document, etc."
Gotchas that survive the switch
- Format handling is unchanged by where the server runs.
sendVideostates that "Telegram clients support MPEG4 videos (other formats may be sent as Document)". An 800 MB MKV that a local server happily uploads can still land as a file icon rather than a playable video. - Thumbnails have their own spec, independent of the file size rules: "The thumbnail should be in JPEG format and less than 200 kB in size. A thumbnail's width and height should not exceed 320."
- Video notes stay small and stay strict.
sendVideoNotesends "a rounded square MPEG4 video of up to 1 minute long", and "Sending video notes by a URL is currently unsupported." - Audio in the music player needs specific formats: per the Bot API, "Your audio must be in the .MP3 or .M4A format."
- Do not self-host reflexively. Telegram's own advice, verbatim: "The majority of bots will be OK with the default configuration, running on our servers. But if you feel that you need one of these features, you're welcome to switch to your own at any time."
FAQ
Does a local Bot API server remove the 50 MB limit? It replaces it. The default 50 MB figure is published with the qualifier "this limit may be changed in the future"; on a local server the documented upload capability becomes "Upload files up to 2000 MB" — higher, but still a fixed ceiling. The limit that genuinely disappears is on the download side: "Download files without a size limit."
Why is it 2000 MB and not 2 GB? That is simply how Telegram writes it in the Bot API documentation. The user FAQ uses "2 GB" and "4 GB" for human accounts; the Bot API uses "2000 MB" for local servers. The FAQ does not attach byte values to its figures, so treat these as separate published strings rather than converting between them.
Can my bot download a 2 GB video a user sent, without a local server?
No. getFile is capped, and Telegram states it with its own hedge: "For the moment, bots can download files of up to 20MB in size." The File object repeats "The maximum file size to download is 20 MB". Users can send far larger files than a default-configured bot can retrieve.
Do I still need to download the file after getFile on a local server?
No — that is one of the five listed changes: "Receive the absolute local path as a value of the file_path field without the need to download the file after a getFile request." On the default server you instead get a link that is guaranteed "valid for at least 1 hour", and you call getFile again once it expires.
Does running my own server change how large a file human users can send? Nothing in the local-server section says so. It describes what your bot will be able to do. The 2 GB / 4 GB figures in the user FAQ are a different set of numbers for a different actor — check the official documentation rather than assuming one affects the other.
Is self-hosting worth it just to move bigger files? Only if you actually need one of the five documented capabilities. If your real problem is a handful of oversized exports, compressing them is faster than operating another service — and it is the same answer that applies on Discord and Slack, where the caps are far lower. More platform breakdowns live in the limits guides.
All quoted limits come from Telegram's official Bot API documentation and user FAQ, checked 16 September 2026. Telegram states in several places that these limits "may be changed in the future" — verify against the official documentation before building around them.
