- Rung one: uploading through the browser? 25 MiB
- Rung two: between 50 and 100 MiB? You'll get a warning
- Rung three: over 100 MiB? The push is blocked
- The ladder as a quick decision table
- When the file shouldn't be in the repo at all
- The catch: file limits sit inside repository limits
- What GitHub's large files page doesn't cover
- My take
- Quick answers
GitHub blocks files larger than 100 MiB, warns you above 50 MiB, and caps browser uploads at 25 MiB. Anything over 100 MiB needs Git Large File Storage or a release instead.
GitHub doesn't have one file size limit. It has three, and which one you hit depends on how big the file is and how you're adding it. Here's each rung of the ladder, as of Nov 2026, based on GitHub's own documentation on large files, with what to do when you reach it.
Think of it as a decision flow. Start with the size of your file, then follow the rung that matches.
Rung one: uploading through the browser? 25 MiB
GitHub says that if you add a file to a repository through the browser, the file can be no larger than 25 MiB. This is the lowest limit, and it catches people who don't use Git on the command line at all, such as designers dropping in an asset or a marketer adding a PDF.
What to do: if your file is under 25 MiB, upload it in the browser and move on. If it's bigger, the browser route is closed. You'll need to push it with Git from your computer instead, which opens up the higher rungs below.
If you're a non-developer who only needs GitHub for the odd file, it's worth asking whether you need it at all. Plenty of interactive content can be built without code; here's how to build interactive content without a developer.
Rung two: between 50 and 100 MiB? You'll get a warning
Once you're pushing with Git, GitHub says you'll receive a warning if you add or update a file larger than 50 MiB. The important detail: the push still succeeds. Nothing is rejected at this stage.
What to do: treat the warning as a prompt to think, not something to click past. Ask whether this file belongs in the repository. Every version of a big file stays in the history, so a file over 50 MiB that you update a few times quietly bloats the repo for everyone who clones it.
Rung three: over 100 MiB? The push is blocked
GitHub blocks files larger than 100 MiB. Beyond that point you must use Git Large File Storage, known as Git LFS. Git LFS keeps the large file outside the normal repository history and stores a small pointer in its place.
What to do: set up Git LFS for that file type before you commit it. If you've already committed the file, removing it from the latest commit may not be enough, because it can still sit in earlier history. Clean that up first, then push again.
The ladder as a quick decision table
| Your file | What GitHub does | Your move |
|---|---|---|
| Up to 25 MiB, added in the browser | Accepts it | Upload as normal |
| Over 25 MiB, added in the browser | Won't accept it in the browser | Push with Git instead |
| Over 50 MiB, pushed with Git | Warns, push still succeeds | Decide if it belongs in the repo |
| Over 100 MiB | Blocks it | Use Git LFS or a release |
When the file shouldn't be in the repo at all
GitHub offers two other routes in its documentation. First, to distribute large files you can create releases on GitHub.com instead of tracking them in the repository. That suits finished things people download, such as installers, zipped builds or datasets that go with a version.
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
Second, GitHub says Git isn't designed to handle large SQL files and recommends a file sharing service for large databases. If you're trying to version a database dump, stop and move it somewhere built for big files.
The catch: file limits sit inside repository limits
Here's what people miss. Staying under 100 MiB per file doesn't mean your repository is healthy. GitHub says it monitors repository health, which is a function of size, commit frequency, contents and structure. It recommends repositories remain small, ideally less than 1 GB, and says less than 5 GB is strongly recommended.
So a repo full of files that each sit just under the warning never triggers a single alert, yet it can still drift well past those recommendations. The per-file rungs tell you when to stop one file. The repository guidance tells you when to stop the habit.
What GitHub's large files page doesn't cover
- Exact Git LFS pricing.
- Any limit on the number of files per repository.
My take
If you only remember one thing, make it the 50 MiB warning. That's the rung where you still have a choice, and acting on it saves you the messier clean-up at 100 MiB. Large binaries belong in Git LFS, in a release or in a file sharing service, not in plain history.
And if you're looking at code tools more broadly, this round-up of coding assistants beyond Copilot is a useful next read.
Quick answers
What is the maximum file size on GitHub?
GitHub blocks files larger than 100 MiB. Anything bigger needs Git Large File Storage.
What is the GitHub upload limit in the browser?
A file added through the browser can be no larger than 25 MiB.
Does GitHub reject files over 50 MiB?
No. Git warns you when you add or update a file larger than 50 MiB, but the push still succeeds.
How big should a GitHub repository be?
GitHub recommends repositories stay small, ideally less than 1 GB, and says less than 5 GB is strongly recommended.
