How to Find Files Larger Than a Size with find -size

find . -type f -size +100M lists every regular file larger than 100 megabytes. The + prefix means "greater than"; the 100M is the threshold. Flip to -100M for "smaller than 100 MB", or drop the sign for "exactly 100 MB" (which almost never matches what you want because of rounding).

This is the right starting point when a server is full and you need to find what's eating the disk. Combined with sort and head, it produces a ranked list of the biggest files in seconds.

Set your values

The one-liner

find :search_path -type f -size +:size

Returns every file under the search path larger than the threshold. Drop -type f to also match directory sizes, though "directory size" in this context means the size of the directory inode itself, not its contents.

What -size actually measures

-size N accepts a numeric value plus a unit suffix:

The sign prefix controls the comparison:

• -size +N returns files larger than N
• -size -N returns files smaller than N
• -size N returns files exactly N (rounded up to whole units)

The rounding rule that catches people: -size 1M matches files whose size, rounded up to the next mebibyte, equals 1 mebibyte. That includes any file between 0 bytes and 1,048,576 bytes. The unit-less +N form uses 512-byte blocks (the POSIX default), which is almost never what you want; always include a suffix.

Find the biggest files on disk

The most useful variant: rank files by size, biggest first.

find :search_path -type f -printf '%s %p\n' | sort -rn | head -20

The output is <size_in_bytes> <path>, sorted from largest. head -20 keeps it scannable; bump that to 50 or 100 for a wider sweep.

For human-readable sizes, pipe through numfmt:

find :search_path -type f -printf '%s %p\n' | sort -rn | head -20 | numfmt --to=iec --field=1 --padding=8

numfmt --to=iec converts bytes to human-friendly sizes (512M, 1.2G). On BSD numfmt isn't installed by default; the inline awk shown above is the cross-platform alternative.

Find files smaller than a size

Same flag, opposite sign:

find :search_path -type f -size -:size

Useful for finding empty-ish files that shouldn't be empty, or for separating small config files from large data blobs in a mixed directory.

Find files of exactly a size (deduplication starting point)

Files with identical sizes are candidates for duplicate detection:

find :search_path -type f -size :size

This is the first step in finding duplicates: group files by size, then hash each group. For a complete dedup workflow use fdupes (Linux) or rdfind, but find -size is the first cut when you don't have those installed.

Find files larger than a size, then delete them

The cleanup pattern. Critical safety habit: always run with -print first to verify what would be deleted.

# Dry run first
find :search_path -type f -size +:size -print
# Then delete
find :search_path -type f -size +:size -delete

-delete has no confirmation and no undo. See find and delete files for the full safe-cleanup checklist.

Find files within a size range

Two -size filters compose by AND:

find :search_path -type f -size +10M -size -100M

This returns files between 10 MB and 100 MB. Tests in find are AND-ed by default; the explicit -and operator is optional.

Show only the directory using the most space

Per-directory disk usage is du's job, not find's, but the two pair naturally:

du -sh :search_path/* 2>/dev/null | sort -rh | head -20

du -sh sums each immediate subdirectory of the search path. sort -rh does a human-readable numeric sort (recognizes K, M, G suffixes). This is the right tool when "what's filling my disk" means "which directory subtree", not "which individual file".

macOS BSD vs GNU find for -size

The differences that bite:

For cross-platform scripts that need to print sizes, prefer stat -f '%z' (BSD) or guard the -printf call with a command -v gfind check.

Common -size mistakes

1. Forgetting the suffix. Bare -size +100 means "more than 100 of the POSIX default unit" which is 512-byte blocks, i.e., more than 51,200 bytes. Almost certainly not what you want. Always specify c, k, M, or G.

2. Confusing case for the suffix. M (mebibytes, 1,048,576 bytes) is different from m (which find treats the same as M on most implementations but isn't guaranteed). Stick with the uppercase forms (k, M, G) for portability.

3. Expecting decimal MB, getting binary MiB. find's M is 1,048,576 bytes (mebibyte), not 1,000,000 bytes (megabyte). For a 100 MB file that's "100,000,000 bytes" by decimal counting, -size +100M would not match because the file is 95.4 MiB. Either think in MiB throughout, or convert decimal sizes to MiB before passing to find.

4. Using -size N thinking it means "exactly N bytes". It means "after rounding up to the next whole unit, equals N". -size 1M matches anything between 0 and 1,048,576 bytes inclusive. For byte-exact comparisons, use -size Nc (with the c byte suffix) and remember that -size 1c still rounds up.

5. Running find / -size +1G without -xdev. Cross-filesystem scans on busy servers can take hours. Add -xdev to stay on one filesystem, or anchor at a specific partition.

6. Forgetting -type f. Without it, find evaluates directories against the size filter too, which is rarely useful (directory inode sizes are tiny and uniform).

When NOT to use -size

Reach for a different tool when:

• You want total disk usage by directory. du -sh (sum) or ncdu (interactive) are purpose-built for this. find returns per-file sizes; aggregating them is awkward.
• You want disk usage including sparse files or compression. find reports the logical size (what ls -l shows). For physical on-disk usage (the actual allocated blocks), use du --apparent-size=false (GNU) or stat -f '%b' (BSD).
• You need real-time monitoring. find is a one-shot scan. For watching disk usage growth, use ncdu or a monitoring stack (Prometheus + node_exporter).
• You're searching for files of a specific structure, not just size. A "large but specific format" search like "log files larger than 100 MB" needs find with both -size and -name, which is fine, but a "1 GB SQLite database" search benefits from file (the magic-byte detector) more than from raw size.

See also

• find Command Cheat Sheet: the full find reference
• Find files modified in the last 7 days: the -mtime companion
• Find and delete files safely: the cleanup-script playbook for -delete
• External: GNU find -size docs, BSD find(1) man page, ncdu

FAQ