free Command on Mac: 22 Answers, 28 MB to 13 GB Free

Type free -h on a Mac and zsh answers zsh: command not found: free. Homebrew doesn't fix it. There is no formula called free, and the procps formula, which ships free on Linux, lists Linux as a requirement and only has Linux bottles. So people go to the Ask Different question about a Terminal version of free: 262 votes, 381,964 views, 22 answers, asked in 2010.

I pulled all 22 answers through the Stack Exchange API and ran every one that can still be run on the M4 Mac mini that runs this business (Mac16,10, 16 GiB, macOS 26.4.1). All of them ran within about ten seconds of each other, starting at 10:32:57 KST on October 4. The amount of free memory they reported ranged from 28 MB to 13.06 GB. The accepted answer gave the 28 MB.

What 22 answers report on one Mac

Eleven of the 22 print a number you could call free or available memory, two of them the same top line. The others print a total, raw pages or swap, point to another tool, or no longer work:

Answer (votes, year)	Method	What it printed here
Accepted (116, 2010)	Python over vm_stat, pages × 4096	Free Memory: 28 MB. Wired: 482 MB
107, 2012	"use vm_stat"	Raw page counts, no units
81, 2012	top -l 1 -s 0 | grep PhysMem	15G used, 286M unused
68, 2013	perl one-liner over vm_stat	free: 120.61 Mi
32, 2013	sysctl vm.swapusage	Swap only: 0.00M
27, 2016	memory_pressure	System-wide memory free percentage: 73%
16, 2012	bash: free + speculative + inactive	Total free: 5,852 MB
15, 2013	sysctl hw.memsize	Total only
10, 2011	vm_stat free pages × 4096	29 MiB free
9, 2014	hostinfo	"Primary memory available: 16.00 gigabytes" (that's the total)
8, 2012	top -l 1 | awk '/PhysMem:/ {print $10}'	An empty line
6, 2011	allmemory	command not found
5, 2017	psutil meminfo.py	Available 5.71G, Used 7.50G
3, 2016	fish function orefalo/free, pages × 4096	free 1.39G, used 2.39G
3, 2013	free-like.sh on the author's blog	Blog didn't respond
1, 2012	dotfiles prompt script, pages × 4096	[13.06G] free
0, 2023	memory_pressure: free + inactive + speculative	5,857 MB

Five answers are not in the table: two that say to use top or htop, one that says Activity Monitor, one that prints the same PhysMem line as the 81-vote answer, and a paste one-liner that prints thousands of pages with no unit. I didn't install fish, so the fish row is that function's arithmetic applied to the same vm_stat snapshot. Every other row is what the command printed.

The accepted answer is off by four

The first line of vm_stat on this Mac reads (page size of 16384 bytes). The accepted answer multiplies every page count by 4096, the Intel page size, so on Apple silicon every number it prints is a quarter of the real one. It reported 482 MB of wired memory. top reported 1,930 MB at the same moment, four times as much.

Four answers hardcode 4096. Their votes add up to 130, and they are wrong in different directions. The accepted answer and the 2011 one-liner divide free memory by four. The fish function divides used memory by four, so a machine using 9.6 GiB looks like it uses 2.4. The dotfiles prompt subtracts wired, active and inactive pages from the total, so shrinking those by four leaves 13.06 G "free" on a 16 GiB machine. The answers that call pagesize or read the page size from the vm_stat header still get it right.

The answer with 8 votes broke a different way. It was written in 2012, when the PhysMem line of top ended with a free figure in the tenth field. Today the line is PhysMem: 15G used (1930M wired, 2315M compressor), 286M unused., which has nine fields, so $10 prints an empty line and exits 0.

Even with the right page size, "Pages free" is the wrong number

Fixing the multiplier only makes the 28 MB into 118 MiB. That still says this Mac is almost full, and it isn't: memory_pressure said 73% free and nothing was in swap. To see which number actually tracks room for new work, I allocated 4 GiB of random bytes in 512 MiB steps, one per second, and sampled after each step:

Counter	Before	Holding 4 GiB	Change
Pages free	139 MiB	66 MiB	stayed between 57 and 139 MiB the whole time
Cache (file-backed + purgeable)	5.69 GiB	3.42 GiB	−2.27 GiB
Compressor, occupied	2.26 GiB	5.90 GiB	+3.64 GiB
psutil available	5.72 GiB	3.87 GiB	−1.85 GiB
kern.memorystatus_level	73% (11.68 GiB)	49% (7.84 GiB)	−3.84 GiB
Swapouts	0	0	none

Free pages hardly moved. The kernel paid for the allocation by dropping file cache and compressing memory, which is why a Mac with 66 MiB free never touched swap. Of the counters I watched, the kernel's own percentage was the only one that fell by close to the 4 GiB I took. psutil's estimate (free + inactive, which its source says is "how Zabbix calculate avail") fell by less than half that. About a minute after I released the memory, free pages briefly read 4,123 MiB. That's the only time I saw a large free figure, and macOS fills it with cache again soon after.

The percentage is what memory_pressure prints as "System-wide memory free percentage". You can read it without the extra output from sysctl -n kern.memorystatus_level.

A free for macOS that reads the page size

Here is what I use now. It keeps the Linux column layout but fills the columns with macOS's own definitions. Used follows the Activity Monitor mapping worked out in an Ask Different answer on why the vm_stat categories don't add up to total RAM: app memory (anonymous minus purgeable), wired, and compressed. Available is the kernel percentage:

#!/bin/sh
# free for macOS: Linux column layout, macOS definitions. Reads the page size; never assumes 4096.
vm_stat | awk -v total="$(sysctl -n hw.memsize)" -v level="$(sysctl -n kern.memorystatus_level)" '
  /page size of/ { ps = $8 }
  { gsub(/\./, "", $NF); v[substr($0, 1, index($0, ":") - 1)] = $NF }
  END {
    G = 1073741824
    app    = (v["Anonymous pages"] - v["Pages purgeable"]) * ps
    wired  = v["Pages wired down"] * ps
    comp   = v["Pages occupied by compressor"] * ps
    cache  = (v["File-backed pages"] + v["Pages purgeable"]) * ps
    free   = (v["Pages free"] + v["Pages speculative"]) * ps
    used   = app + wired + comp
    printf "%-6s %9s %9s %9s %9s %9s %9s\n", "", "total", "used", "free", "compr", "cache", "avail"
    printf "%-6s %8.2fG %8.2fG %8.2fG %8.2fG %8.2fG %8.2fG\n", "Mem:", total/G, used/G, free/G, comp/G, cache/G, total*level/100/G
  }'
sysctl -n vm.swapusage | awk '{ printf "%-6s %9s %9s %9s\n", "Swap:", $3, $6, $9 }'

Run before the allocation test, it printed:

           total      used      free     compr     cache     avail
Mem:      16.00G     9.56G     0.27G     2.26G     5.76G    11.68G
Swap:      0.00M     0.00M     0.00M

Save it as ~/bin/free, chmod +x it, and free works again. It takes no flags; it always prints GiB. Linux's shared column is gone because vm_stat has no equivalent, and compr is new because Linux has nothing like the compressor. To watch it change, the watch command on Mac has its own Linux catch.

Linux free columns, mapped

Linux free	Closest macOS source
total	sysctl -n hw.memsize
used	anonymous − purgeable + wired + compressor pages (Activity Monitor's "Memory Used")
free	Pages free + Pages speculative; usually tiny, and that's fine
buff/cache	File-backed pages + Pages purgeable
available	kern.memorystatus_level % of total
Swap	sysctl vm.swapusage (current), not vm_stat's Swapouts

That last row matters. Swapouts counts every write since boot, so it only grows. I measured the difference in vm_stat swap usage on Mac. If you are sizing a machine instead of reading one, how much RAM a home server needs uses these counters on the same Mac. This is the same pattern as nproc on Mac and pstree on Mac: the Linux name is missing, and the obvious replacement answers a slightly different question.

FAQ

Is there a free command on Mac?

No. macOS doesn't include free, and Homebrew has no formula for it; procps, which provides free on Linux, is a Linux-only formula. Use memory_pressure or sysctl kern.memorystatus_level for available memory, vm_stat for page counts, or a small script that reads the page size from vm_stat.

Why does vm_stat show so little free memory on a Mac?

macOS keeps almost all RAM in use as file cache and compressed memory, and gives it back when an app needs it. On a 16 GiB M4 Mac mini, free pages stayed under 140 MiB while 4 GiB was allocated, and nothing went to swap. Low "Pages free" is normal.

What page size does vm_stat use on Apple silicon?

16,384 bytes. Intel Macs use 4,096. vm_stat prints the value on its first line, and scripts that multiply page counts by 4096 report a quarter of the real figure on M-series Macs.

Method: on 2026-10-04 I fetched every answer to Ask Different question 4286 from the Stack Exchange API (22 answers; votes and views as of that day) and ran each runnable recipe as written on a Mac mini (Mac16,10, macOS 26.4.1 build 25E253, 16 GiB, six days of uptime, no swap in use) between 10:32:57 and about 10:33:10 KST, so the readings are seconds apart, not simultaneous. psutil was 7.2.2 in a throwaway venv, and its formula is quoted from psutil/_psosx.py. The fish function was not run: I applied its arithmetic to the same vm_stat output. The free-like.sh blog returned a 301 to HTTPS, and the HTTPS URL didn't respond. The allocation test used os.urandom in 512 MiB chunks, with one sample per step from vm_stat, sysctl and psutil. The Homebrew facts come from brew info and the formulae.brew.sh API. I didn't test Intel Macs, older macOS versions or a machine under real memory pressure, so how kern.memorystatus_level behaves near swap is unmeasured here.