Ghostty vs iTerm2 in 2026: Which Mac Terminal Is Actually Faster Day to Day

Short answer: Ghostty is faster in the places you feel with your hands, and iTerm2 is faster in the places that save you minutes. Ghostty starts quicker, keeps up better when a command floods the screen, and feels tighter under the fingers because it does less work per keystroke. iTerm2 wins on the workflow features that eliminate work entirely, mainly its tmux control mode, triggers, and session restore.

And the honest third answer, the one nobody selling a terminal wants to lead with: if your terminal feels slow today, there is a very good chance the terminal is not the problem. Your shell startup file is. I have watched people migrate terminals to fix a 900 millisecond prompt that was caused by a version manager loading on every new tab.

Here is how I would decide, and how to measure it yourself instead of trusting anyone's benchmark screenshot.

What "fast" actually means in a terminal

People say "faster" and mean at least four different things. They do not correlate, and only some of them matter.

Input latency. The time from pressing a key to seeing the glyph. This is the one your nervous system notices, and it is the one nobody measures properly, because measuring it correctly requires filming the screen. Dan Luu's terminal latency work is the reference here, and the takeaway that has held up is that terminal emulators vary by amounts that are perceptible, and that variation is not predicted by how modern the app looks.

Startup and first prompt. How long from Command-N to a usable prompt. You do this dozens of times a day, so it compounds more than throughput ever will.

Throughput. How fast the terminal can render a flood of output, for example cat on a large log or a verbose build. Everyone benchmarks this because it is easy to benchmark. It matters far less than the benchmark culture implies, with one exception noted below.

Behavior under load. When output is flooding, does the UI stay responsive? Does Control-C register immediately? Does scrolling stay smooth? This is where cheap terminals fall apart and where the difference is actually worth money.

Where Ghostty wins

Ghostty is written in Zig by Mitchell Hashimoto, uses native macOS UI rather than a cross-platform toolkit, and renders through Metal. It is free and open source, and it runs on macOS and Linux.

The architectural point that matters: Ghostty was designed recently, with GPU rendering and low latency as goals from the first commit, and it carries no compatibility debt. iTerm2 is roughly two decades of accumulated features, and it added its Metal renderer to an existing architecture rather than being built around one.

In practice, on Apple Silicon, that shows up as:

• Faster cold start and faster new windows. The gap is small in absolute terms and large in perceived terms, because it happens constantly.
• Better composure during output floods. Long builds and large log dumps do not turn the window into a slideshow.
• Less overhead per keystroke, which is the part that reads as "crisp" and is very hard to argue with once you have felt it.

Ghostty also ships sane defaults, which is a real speed feature. The config file lives at ~/.config/ghostty/config, it is plain text, and you can put it in your dotfiles repo in about a minute. It supports the Kitty keyboard and graphics protocols, native tabs and splits, and a quick drop-down terminal.

Where iTerm2 wins

iTerm2's advantage is not milliseconds. It is that some of its features delete entire steps from your day.

tmux control mode. Running tmux -CC gives you real tmux sessions rendered as native iTerm2 tabs and splits. You get tmux persistence (detach, close the laptop, reattach with everything alive) with native scrollback, native mouse behavior, and native Command-key navigation. If you work on remote servers, this single feature outweighs any latency difference. Nothing in Ghostty replaces it.

Triggers. Regex rules that fire on output: highlight a line, ring a bell, capture a value, run an action. For anyone watching long log streams, this is a genuine time saver.

Instant replay, session restore, and the search UI. iTerm2's search and its ability to restore your window layout after a restart are more mature. So is its scrollback handling at very large sizes.

Deep configurability. Profiles, per-profile keybindings, a Python API. If your workflow is already built on this, migrating is a downgrade regardless of frame times.

One note relevant to privacy-minded readers: iTerm2's AI features live in a separately installed plugin, so they are not present in the base application unless you deliberately add them.

The part most benchmarks skip: your shell is the bottleneck

Before you switch terminals, spend five minutes here. This is usually where the entire perceived speed problem lives.

# How long does an interactive shell take to become usable?
hyperfine --warmup 3 'zsh -i -c exit'

Anything above roughly 150 to 200 milliseconds is worth investigating, and anything near a second is why your terminal feels bad. To find the culprit in zsh, add zmodload zsh/zprof at the very top of .zshrc and zprof at the bottom, then open a new shell.

The usual suspects, in order of how often I find them:

1. Version managers (nvm, rbenv, pyenv, conda) initializing eagerly on every shell. Lazy-load them.
2. A prompt that shells out to git status in large repositories on every render. Use a prompt that does this asynchronously.
3. Plugin frameworks loading dozens of files serially.
4. Shell completion being rebuilt on every start rather than cached.

Fix those and both terminals will feel dramatically faster, which is a slightly annoying but important conclusion.

Measure the terminals yourself, on your machine

Do not trust my numbers or anyone else's. Hardware, display refresh rate, font, and configuration all move the result. Run the same tests in both apps, on the same machine, with the same font and window size.

Throughput. Generate a large file and time it:

yes "the quick brown fox jumps over the lazy dog" | head -n 500000 > /tmp/flood.txt
time cat /tmp/flood.txt

For something more rigorous across escape sequences and scrolling, use vtebench from the Alacritty project, which exercises patterns that real programs produce rather than plain text.

Responsiveness under load. Start that flood and immediately press Control-C. Count how long until the prompt returns. Then try scrolling while it runs. This is subjective, and it is also the most predictive test on this list.

Latency. You cannot measure this with software on the same machine you are testing. The practical home version is to film the screen with a phone at the highest slow-motion frame rate it supports, press a key, and count frames from key contact to glyph appearance. Repeat ten times and take the median. It is crude and it is still far better than guessing.

Settings that quietly cost you frames

Both applications will be slower if you ask them to do more work. Before concluding that an app is slow, check:

• Transparency and background blur. The most expensive visual option in any terminal, by a wide margin. Turn it off and re-test.
• Ligatures. Programming ligatures require extra text shaping work per line.
• Unbounded scrollback. Set a real limit. Tens of thousands of lines is plenty, and you should be piping to a file or a pager for anything larger anyway.
• Display refresh. Rendering is bounded by your monitor. A 60 Hz external display puts a hard floor under every terminal on your desk that no software can remove.
• iTerm2's GPU renderer. Confirm it is enabled, and read iTerm2's documentation on the conditions under which it falls back to the software renderer. Some feature combinations disable it, and that fallback is exactly the kind of thing people mistake for "iTerm2 is slow."

What I actually run

Ghostty as the daily driver, because the majority of my terminal use is short-lived local work where startup speed and keystroke feel dominate. iTerm2 stays installed, and I open it for remote sessions where tmux -CC earns its place, and for anything involving triggers on a long-running log stream.

That is not a compromise. Both are free, both are actively maintained, and the cost of keeping both is a few hundred megabytes of disk. Picking one terminal to be loyal to is a strange hill to defend when the alternative is having the right tool open.

If you are switching to Ghostty, budget an evening. Port your font, keybindings, and color scheme, put the config in your dotfiles, and give it two weeks before deciding. Two days is not long enough to unlearn muscle memory, and most switching regret is muscle memory misreported as performance.

FAQ

Is Ghostty stable enough to be a daily driver? Yes. It reached 1.0 and has been in wide use since. Treat any specific feature you depend on as something to verify yourself rather than assume, especially unusual keybindings and terminal protocol features.

Does Ghostty support tmux? It runs tmux exactly as any terminal does. What it does not have is iTerm2's control mode integration, where tmux windows become native tabs. If that integration is central to your workflow, iTerm2 remains the better tool.

Will switching terminals speed up my builds? Almost never. Terminal rendering is a bottleneck only when a build produces enormous output. If that is your situation, quiet the build output first, because that is the larger win.

Is Alacritty or WezTerm faster than both? Alacritty is minimal and quick, and it deliberately omits tabs and splits, so you pair it with tmux. WezTerm is highly capable and configured in Lua. Both are reasonable. The measurement approach in this article works for them without changes.

Which one should I pick if I do not want to think about it? Ghostty. Good defaults, native feel, fast where it counts, and nothing to configure before it is usable.