Git LFS Storage Calculator
Project Git LFS storage and bandwidth usage from large binary file tracking.
About Git LFS Storage Calculator
Git LFS bills storage and bandwidth separately from repository size. Formula: storage = lfs_objects × avg_size; monthly_bandwidth = monthly_pulls × avg_size. Every clone, fetch or checkout that touches an LFS-tracked file re-downloads it (unless cached), so bandwidth usage scales with team size and CI activity, not just repository growth.
Formulas
LFS storage
storage_GB = lfs_objects × avg_size_MB / 1024
- lfs_objects
- Number of LFS-tracked objects
- avg_size_MB
- Average object size (MB)
Monthly bandwidth
bandwidth_GB = monthly_pulls × avg_size_MB / 1024
- monthly_pulls
- LFS object downloads per month
- avg_size_MB
- Average object size (MB)
Worked example
With the default values below, Git LFS Storage Calculator returns LFS Storage Footprint of 7.32. Change any input above and every figure here is recalculated in your browser.
Inputs used
- LFS Objects Trackedaccepts 0–10,000,000 objects
- 500 objects
- Average Object Sizeaccepts 0–1,000,000 MB
- 15 MB
- Monthly Pulls/Clonesaccepts 0–10,000,000 pulls
- 300 pulls
Results
- LFS Storage Footprint
- 7.32 GB
- Monthly LFS Bandwidth
- 4.39 GB
- LFS Storage Footprint
- 7,500 MB
- Monthly LFS Bandwidth
- 4,500 MB
Step by step
- 1Storage: objects × avg size= 7500MB
- 2Monthly bandwidth: pulls × avg size= 4500MB
Assumptions and limits
- The result is derived only from the 3 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax or compounding frequency into account.
- Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
Frequently Asked Questions
Why is my LFS bandwidth bill higher than expected?
Every CI job that clones the repo re-downloads all LFS objects referenced by the checked-out commit unless you cache the LFS store between runs — this is the most common cause of runaway bandwidth usage.
How do I reduce LFS bandwidth costs?
Cache `.git/lfs` between CI runs, use `git lfs fetch --recent` to skip old history, and consider `GIT_LFS_SKIP_SMUDGE=1` for CI jobs that don't need the actual file content.
Does deleting an LFS-tracked file reduce storage?
No — like regular Git objects, LFS objects remain in history until you rewrite it (e.g. `git lfs prune` for local caches, or provider-specific history rewriting for the remote store).
What files should go in Git LFS?
Binary or large files that change often and don't diff well as text — images, videos, datasets, compiled models, design files — so history doesn't balloon with full copies of every version.