How to fix remote: error: File large_file.zip is 150.00 MB; this exceeds GitHub's file size limit of 100.00 MB in Git

GitINTERMEDIATEMEDIUMUpdated Dec 6, 2025· 294 views

GitHub rejects pushes containing files larger than 100 MB. To fix this, you must remove the large file from your repository history using BFG Repo-Cleaner or git filter-repo, then either exclude the file or use Git LFS (Large File Storage) for tracking large files.

Quick fix

Fixes remote: error: File large_file.zip is 150.00 MB; this exceeds GitHub's file size limit of 100.00 MB

# Find all files larger than 100MB in your repository history
git rev-list --objects --all | \
  git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' | \
  awk '/^blob/ {print substr($0,6)}' | \
  sort -rnk2 | \
  head -20

# Or use git-sizer for a comprehensive report
# Install: brew install git-sizer (macOS) or download from GitHub
git-sizer --verbose
  1. Identify the problematic file(s) and commit(s)
  2. Remove the large file using BFG Repo-Cleaner (Recommended)
  3. Alternative: Remove using git filter-repo
  4. If the file is only in recent commits: Interactive rebase
git — error
# Find all files larger than 100MB in your repository history
git rev-list --objects --all | \
git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' | \
awk '/^blob/ {print substr($0,6)}' | \
sort -rnk2 | \
head -20
# Or use git-sizer for a comprehensive report
# Install: brew install git-sizer (macOS) or download from GitHub
git-sizer --verbose
remote: error: File large_file.zip is 150.00 MB; this exceeds GitHub's file size limit of 100.00 MB

What this error means

This error occurs when you attempt to push a commit to GitHub that contains a file exceeding 100 MB. GitHub enforces a strict file size limit of 100 MB for individual files in repositories. The important thing to understand is that even if you delete the large file from your working directory, Git still stores it in your commit history. Every commit that ever contained the file needs to be rewritten to truly remove it. This is why simply deleting the file and committing the deletion doesn't fix the problem. GitHub's 100 MB limit exists to ensure repository performance and prevent abuse. Large binary files don't version well in Git anyway - each change creates a complete copy rather than a diff. For files over 100 MB, GitHub recommends using Git LFS, which stores large files on external storage while keeping lightweight pointer files in your repository. Note: GitHub also displays a warning for files larger than 50 MB, though these can still be pushed. The hard limit is 100 MB, and pushing files larger than this will be completely blocked.

Typical symptoms

  • Push fails with 'exceeds GitHub's file size limit of 100.00 MB' error
  • Push rejected even after deleting the large file from your working directory
  • Error message references a file you added in a previous commit
  • Error appears after adding datasets, compiled binaries, or media files
  • CI/CD pipeline fails during git push step
  • Force push also fails with the same file size error
  • Error mentions multiple files when several large files were committed
  • Push works to other remotes but fails specifically for GitHub

Common causes

  1. Committing files larger than 100 MB to the repository
  2. Large file exists in commit history even after deletion from working directory
  3. Accidentally committing build artifacts, datasets, or media files
  4. Merging a branch that contains commits with large files
  5. IDE or editor auto-saving large temporary files in the repository
  6. Forgetting to add large file patterns to .gitignore before committing
  7. Package dependencies or node_modules accidentally committed
  8. Database dumps or backup files committed to the repository

How to fix "remote: error: File large_file.zip is 150.00 MB; this exceeds GitHub's file size limit of 100.00 MB"

1Identify the problematic file(s) and commit(s)

First, identify exactly which files are too large and where they appear in your history:

bash
# Find all files larger than 100MB in your repository history
git rev-list --objects --all | \
  git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' | \
  awk '/^blob/ {print substr($0,6)}' | \
  sort -rnk2 | \
  head -20

# Or use git-sizer for a comprehensive report
# Install: brew install git-sizer (macOS) or download from GitHub
git-sizer --verbose

Find which commits contain the large file:

bash
# Find commits that modified the large file
git log --all --full-history -- "path/to/large_file.zip"

# See the size of a specific file
git ls-tree -r -l HEAD | grep large_file

Take note of the file path - you'll need it for the removal steps.

2Remove the large file using BFG Repo-Cleaner (Recommended)

BFG Repo-Cleaner is 10-720x faster than git filter-branch and much simpler to use. It's the recommended tool for removing large files.

Step 1: Install BFG

bash
# macOS
brew install bfg

# Or download the JAR file from https://rtyley.github.io/bfg-repo-cleaner/
# Requires Java 11 or higher

Step 2: Create a fresh clone (mirror)

bash
# Clone a bare repository (required for BFG)
git clone --mirror https://github.com/username/repo.git repo.git
cd repo.git

Step 3: Run BFG to remove large files

bash
# Remove all files larger than 100MB
bfg --strip-blobs-bigger-than 100M

# Or remove a specific file by name
bfg --delete-files large_file.zip

# Or remove files matching a pattern
bfg --delete-files "*.zip"

Step 4: Clean up and push

bash
# Clean up the repository
git reflog expire --expire=now --all
git gc --prune=now --aggressive

# Push the cleaned history (requires force push)
git push --force

Important: BFG protects your current HEAD commit by default. If the large file is in your latest commit, first delete it and commit the deletion, then run BFG.

3Alternative: Remove using git filter-repo

git filter-repo is the modern, officially recommended replacement for git filter-branch. It's fast and handles edge cases well.

Install git filter-repo:

bash
# macOS
brew install git-filter-repo

# pip (any platform)
pip install git-filter-repo

# Ubuntu/Debian
apt install git-filter-repo

Remove the large file:

bash
# Remove a specific file from all history
git filter-repo --invert-paths --path "path/to/large_file.zip"

# Remove multiple files
git filter-repo --invert-paths --path "file1.zip" --path "file2.tar.gz"

# Remove files matching a pattern
git filter-repo --invert-paths --path-glob "*.zip"

# Remove all files larger than 100MB
git filter-repo --strip-blobs-bigger-than 100M

After filtering, push the changes:

bash
# Re-add the remote (filter-repo removes it for safety)
git remote add origin https://github.com/username/repo.git

# Force push all branches
git push origin --force --all
git push origin --force --tags
4If the file is only in recent commits: Interactive rebase

If the large file was added in the last few commits and hasn't been pushed yet, interactive rebase is simpler:

For a file added in the last commit:

bash
# Undo the last commit, keeping changes staged
git reset --soft HEAD~1

# Remove the large file from staging
git rm --cached path/to/large_file.zip

# Add to .gitignore
echo "large_file.zip" >> .gitignore

# Re-commit without the large file
git add .gitignore
git commit -m "Your original commit message"

For a file added a few commits ago:

bash
# Start interactive rebase (replace N with number of commits)
git rebase -i HEAD~N

# In the editor, change 'pick' to 'edit' for the commit that added the file
# Save and close

# Remove the large file
git rm --cached path/to/large_file.zip
git commit --amend --no-edit

# Continue the rebase
git rebase --continue

Warning: Don't use interactive rebase if you've already pushed these commits to a shared branch - use BFG or filter-repo instead.

5Set up Git LFS for large files you need to keep

If you need to version control large files, use Git Large File Storage (LFS). It stores large files on external storage while keeping pointer files in your repo.

Step 1: Install Git LFS

bash
# macOS
brew install git-lfs

# Windows (comes with Git for Windows, or)
git lfs install

# Ubuntu/Debian
apt install git-lfs

# Initialize LFS for your user account (once per machine)
git lfs install

Step 2: Track large file patterns

bash
# Track specific file types
git lfs track "*.zip"
git lfs track "*.psd"
git lfs track "*.mp4"

# Track a specific file
git lfs track "path/to/large_file.zip"

# This creates/updates .gitattributes

Step 3: Commit the .gitattributes file

bash
git add .gitattributes
git commit -m "Configure Git LFS tracking"

Step 4: Migrate existing large files to LFS

bash
# Import existing files into LFS (rewrites history)
git lfs migrate import --include="*.zip" --everything

# Force push the rewritten history
git push origin --force --all

Important: GitHub offers 1 GB free LFS storage and 1 GB bandwidth per month. Additional storage is available for purchase.

6Prevent future large file commits

Set up safeguards to prevent accidentally committing large files again:

Update .gitignore:

bash
# Add common large file patterns to .gitignore
cat >> .gitignore << 'EOF'
# Large files
*.zip
*.tar.gz
*.rar
*.7z
*.mp4
*.mov
*.psd
*.ai

# Build artifacts
dist/
build/
*.exe
*.dll
*.so
*.dylib

# Dependencies
node_modules/
vendor/

# Data files
*.csv
*.sql
*.sqlite
data/
EOF

git add .gitignore
git commit -m "Update .gitignore to exclude large files"

Set up a pre-commit hook:

bash
# Create a pre-commit hook
cat > .git/hooks/pre-commit << 'EOF'
#!/bin/bash
# Prevent commits of files larger than 50MB

MAX_SIZE=$((50 * 1024 * 1024))  # 50MB in bytes

for file in $(git diff --cached --name-only); do
    if [ -f "$file" ]; then
        size=$(wc -c < "$file")
        if [ $size -gt $MAX_SIZE ]; then
            echo "Error: $file is larger than 50MB"
            echo "Consider using Git LFS for large files"
            exit 1
        fi
    fi
done
EOF

chmod +x .git/hooks/pre-commit

Use pre-commit framework for team-wide enforcement:

yaml
# .pre-commit-config.yaml
repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.5.0
    hooks:
      - id: check-added-large-files
        args: ['--maxkb=50000']  # 50MB
7Force push the cleaned repository

After removing the large file from history, you need to force push to update the remote:

bash
# Verify the large file is removed
git rev-list --objects --all | \
  git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' | \
  awk '/^blob/ && $3 > 100000000 {print}'

# Should return empty if all large files are removed

# Force push to GitHub
git push origin main --force

# Push all branches if needed
git push origin --force --all

# Push tags
git push origin --force --tags

Important warnings about force pushing:
- Force pushing rewrites history - all collaborators must re-clone or rebase
- Never force push to a shared branch without coordinating with your team
- Consider using --force-with-lease for safety:

bash
# Safer force push - fails if remote has new commits
git push origin main --force-with-lease

After force pushing, inform your team:

bash
# Team members should run:
git fetch origin
git reset --hard origin/main

# Or re-clone the repository
git clone https://github.com/username/repo.git

Advanced notes

### Why Deleting the File Doesn't Work

Git is a content-addressable filesystem - every version of every file ever committed is stored forever (until garbage collected). When you delete a file and commit, you're just adding a new commit that doesn't include that file. All previous commits still contain it.

This is why you need history-rewriting tools like BFG or git filter-repo. They create new commits with the same content minus the large file, then update all branch pointers to the new history.

### GitHub vs GitLab vs Bitbucket Limits

| Platform | File Size Limit | Push Size Limit | LFS Support |
|----------|-----------------|-----------------|-------------|
| GitHub | 100 MB | 2 GB | Yes (1 GB free) |
| GitLab | 100 MB* | None | Yes (10 GB free) |
| Bitbucket | 100 MB | 2 GB | Yes (1 GB free) |

*GitLab limits can be configured by admins for self-hosted instances.

### Git LFS Costs and Alternatives

GitHub LFS pricing:
- Free: 1 GB storage, 1 GB bandwidth/month
- Data packs: $5/month for 50 GB storage + 50 GB bandwidth

Alternatives to Git LFS:
- git-annex: More flexible, good for scientific data
- DVC (Data Version Control): Designed for ML/data science
- External storage: Store in S3/GCS and reference in README

### Recovering from a Failed Push

If you pushed some commits before hitting the limit:

bash
# Find what commits made it to the remote
git log origin/main..HEAD

# You may need to coordinate with your team
# before rewriting shared history

### Working with Protected Branches

If the target branch is protected and doesn't allow force pushes:

1. Temporarily disable branch protection (Settings > Branches)
2. Force push the cleaned history
3. Re-enable branch protection

Or create a new branch, cherry-pick commits without the large file, and merge via PR.

### Large File Detection Before Commit

Use git hooks or CI checks to catch large files early:

bash
# GitHub Actions workflow to check file sizes
name: Check File Sizes
on: [push, pull_request]
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Check for large files
        run: |
          find . -type f -size +50M -not -path "./.git/*" | while read f; do
            echo "::error file=$f::File exceeds 50MB"
            exit 1
          done

### BFG vs git filter-repo vs git filter-branch

| Tool | Speed | Ease of Use | Maintenance |
|------|-------|-------------|-------------|
| BFG | Very fast | Very easy | Stable |
| git filter-repo | Fast | Easy | Active |
| git filter-branch | Slow | Complex | Deprecated |

Recommendation: Use BFG for simple file removal, git filter-repo for complex rewrites.

### Shallow Clones and Large Files

If you only need recent history, shallow clones can avoid downloading old large files:

bash
# Clone only the last 100 commits
git clone --depth 100 https://github.com/username/repo.git

# Clone only a specific branch
git clone --single-branch --branch main https://github.com/username/repo.git

This won't help if the large file is in recent commits, but can speed up cloning repositories where large files were removed from history long ago.

Frequently asked questions

What does "remote: error: File large_file.zip is 150.00 MB; this exceeds GitHub's" mean?
This error occurs when you attempt to push a commit to GitHub that contains a file exceeding 100 MB. GitHub enforces a strict file size limit of 100 MB for individual files in repositories. The important thing to understand is that even if you delete the large file from your working directory, Git still stores it in your commit history.
How do I fix "remote: error: File large_file.zip is 150.00 MB; this exceeds GitHub's"?
GitHub rejects pushes containing files larger than 100 MB. To fix this, you must remove the large file from your repository history using BFG Repo-Cleaner or git filter-repo, then either exclude the file or use Git LFS (Large File Storage) for tracking large files.
What causes "remote: error: File large_file.zip is 150.00 MB; this exceeds GitHub's"?
Committing files larger than 100 MB to the repository Large file exists in commit history even after deletion from working directory Accidentally committing build artifacts, datasets, or media files
Is the "remote: error: File large_file.zip is 150.00 MB; this exceeds GitHub's" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading