alt Hacker NewsState of Terminal Emulators in 2025: The Errant Champions
Comments
While the article title is true (errant is a very specific and concise word), to me it did not convey clear enough that this is just ucs-detect / unicode support (compliance?) ranking. The article title "State of Terminal Emulators in 2025" implied a larger comparison of terminal emulators than just ucs-detect.
Personally I also question the practicality or usefulness of this table because why should I care about having "the best unicode support"?
Curious, I briefly compared top ranked emulator (ghostty) on how fast it can print 10000 lines and it took 432ms compared to alacritty, ranked 18 (50ms), and Terminal.app, ranked 29 (50ms). If this is the trade-off to have the best unicode support, why should I want it? Why does it matter?
It's interesting that none of the programs commonly known as "terminal emulators" actually emulate a terminal.. we can do that now though. https://zork.net/~st/jottings/Real-VT102-emulation-with-MAME...
I would avoid doing the PTY thing and instead do this (works on WSL if MAME is the windows version):
$ sudo socat TCP-LISTEN:1234,reuseaddr,fork EXEC:"/sbin/agetty -L - 9600 vt102",pty,setsid,ctty,stderr
$ mame -nomouse vt102 -rs232 null_modem -bitb socket.localhost:1234
I've had an idea to try to write a sort of high-level-ish VT220 emulator that pokes and patches the ROMs and the system to let you control it with the mouse, paste and stuff, lets you just doubleclick it to get a terminal, etc... I forgot about that until seeing this. Nobody would use it for more than 5 minutes but it would be funny.
Pretty nice to see KDE's Konsole rank really high, especially if you take performance/test elapsed time into account. Considering it's a decades-older workhorse compared to the new star ghostty, not too shabby that it's kept up.
Some vaguely related things:
- VTTEST <https://invisible-island.net/vttest/vttest.html>, which tests capabilities from VT-100 to VT-520 terminals.
- Markus Kuhn's UTF-8 test <https://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-test.txt>.
I have been pretty happy with Alacritty for a while but just tried Ghostty and am a little bit mind-blown. The fact that it has a built-in theme picker is insanely convenient for people working on multiple computers at the same time(so the same theme might not work everywhere).
Overall, it literally looks like a better Alacritty alternative. The creator(s) did a great job!
I appreciate this analysis is on the state of terminal emulators, but I'm curious how well the integrated terminals that come bundled in code editors/IDEs also perform. For example, where does Zed's integrated terminal fit in the rankings? VS Code (and its derivatives)? JetBrains, Sublime Text?
Terminal emulators are caught between emulating terminals and teletypes of the past and implementing new features and unicode is one of the struggles. The way most terminals and wcwidth handle the width of characters sometimes is not correct but preserving behavior is important for compatibility. It is possible that its just not worth trying to handle all unicode perfectly in a terminal. Its pretty good for legacy stuff and sysadmin. We have other ways of doing things remotely like html that might be more appropriate for ZWJ emoji and languages with complicated text shaping/rendering.
Foot is excellent. Wayland only, but it is very fast to launch, and uses few resources. I love it.
No love for Windows Terminal? I know that linux has a much richer terminal ecosystem, but WT ranks a lot higher than a wide breadth of terminal emulators on linux now. Could anyone have imagined that 10 years ago?
Interesting that xterm is written off as not supporting sixel, when in actuality it supports both full SIXEL and ReGIS and Tek 4010, with 24bit colour IIRC.
It's just not enabled by default.
So the state of 2025 then tests a VTE that is from 2023? 4 major releases behind? And through a GTK 3 app, not even a GTK 4 one which will use the GPU?
I'd find it very useful to be able to query a terminal to see if it has font support for a given list of characters.
This would allow TUIs to use recent unicode characters which may not be supported (e.g. Symbols for Legacy Computing), or private use characters (e.g. powerline symbols & font-awesome icons), while falling back to a more universally supported character in terminals that do not support them.
The terminal that comes with macOS version ends on the 29th place in the results.
I can't remember the last time I used a non-ascii character in the terminal. I know that's not the case for everyone, and they deserve good terminals too, but it does mean that the criteria measured here have no relevance to my choice of a good terminal for me.
I see Ghostty does not support (and does not plan on adding support for) Sixels, instead preferring the Kitty image protocol.
Now if the Kitty image protocol is so great and the Sixel stuff is so bad, ~~why is it only used in Kitty and Ghostty?~~
*Edit: it's also supported in Konsole, WezTerm, ... but still I'm interested in why we have 2 competing protocols right now.
I'd like to see the key-to-pixel latency speed championship.
Unicode support in terminals is kind of a mess for TUI software developers. There is no good way to know how many columns a Unicode character will take, because terminals use different grapheme clustering algorithms.
For a text editor I'm making I ended up with:
> Unicode support is limited to what common modern terminal emulators support. In Hat, "character" is a Unicode codepoint. So no grapheme clustering, no variation selection, no ZWJs, no terminal emulator-specific logic. As long as every buffer byte is displayed and editable, we're ok.
https://github.com/ivanjermakov/hat/blob/master/CONTRIBUTING...
And I do basic codepoint range check to find its approximate width: https://github.com/ivanjermakov/hat/blob/00782dbaee1e1a814ce...
While there's vscode console, I think that bare Xterm.js would be a nice addition to the list.
The list does not include DECterm.
https://stuff.mit.edu/afs/net/dev/system/pmax_ul3/srvd.74/us...
Maybe it's hard to find these days. However it had the best VT220 emulation I have seen running on X Window System.
I will note that I have not seen a terminal emulator that supports the "double wide" and "double high, double wide" character modes of the VT100. Those giant letters were kinda fun. (<esc>#3, <esc>#4, and <esc>#6 if my memory serves me right.)
These terminals properly handle single + double width fonts. But the same thing could work with single + half width fonts, so i,j,l,:,!,.,' and space would fit in half the width. Does anyone know of such a font? I searched but couldn't find any bi-spaced font with full/half width cells.
It would not only fit more text on a line, while (probably) also being nearly as pleasing as a proportional font, but it would also still perfectly align indents. I think it could be a great markdown font.
> And then my next windmill that I'm looking at is variable-sized text in the terminal. So when I'm catting a markdown file, I want to see the headings big.
Is this something people actually want?
One of the reasons I enjoy using the terminal is because the text is of a fixed size and monospaced. Even colors and bold text can be distracting at times. I certainly don't want my terminal to render Markdown...
I imagine the feature could be disabled, but still. I'm all for improving terminal UIs, but let's not turn them into a web browser.
I used iterm2 for ages, but then somehow defaulted to terminal.app. It is fast and that is basically all i need from a terminal emulator, everything else is taken care of by tmux.
The same part of me that is shy to install Chrome extensions is shy to try non-standard terminals. I'd like the thing I type my passwords into to be as trusted as possible.
SteamOS comes with Konsole, so that's what I've got installed in Linux. What am I missing out on by not using e.g. Ghostty?
(I know this article is about Unicode support, but I don't think I've ever had a hard time using a terminal because of its level of Unicode support.)
I wonder how long until terminals support half of the XWindows protocol (as some weird combination of Markdown, HTML and escape codes, most probably). This is not a diss, I would actually be pretty happy with a pared-down GUI protocol in the terminal with extensive Unicode support.
It's interesting that these are rankings, but in some cases the individual points are make or break for a given use case. For example, none of the emulators ranked higher than iTerm2 support Tek 4010 mode, which iTerm2 does support. So that's the one I keep using.
`st` used to have a patch set for sixel graphics on its web site. I use an old version all the time to do gnuplots in terminals with nice scrollback. It seems to have been retired in favor of the kitty graphics protocol.
Why are we still emulating dumb terminals in 2025?
> Kitty and Ghostty are the only terminals that correctly support Variation Selector 15,
Really? Because IIRC they "support" it by treating the preceding emoji character as being Narrow instead of Wide. This is completely unsupported by anything in the Unicode standards: the codepoint sequences that affect the East Asian Width of their first codepoints are explicitly enumerated, and none of them have emojis and/or VS-15 in it. So no, it's not "correctly" supported. Emojis are Wide (terminal width 2) with or without VS-15/VS-16, and if fonts have textual renditions of them that are only 1 cell wide, well, that's the fonts' problems, just as fonts that have e.g. glyphs for Playing Cards block with visible width of 1.5 (I am looking at you, Google Noto) are wrong too.
I would use neovide over anything else if they supported macos tabs. It’s the termianl with the best font readability for me.
no xterm.js? it's a very good cross-platform terminal emulator
[dead]
I still use PuTTY and a MAX232EACwhateverthefuck chip for embedded hardware stuff with a DB9 cable thats been plugged in and out more times than your mom on prom night.
Should I switch to something else or just keep on truckin?
Work had me using the Windows Terminal for the first time ever after a life of developing on Linux. I got immediately hooked on the smart Ctrl+C and Ctrl+V (without needing to use Shift like on Linux!)
For those not knowing, Windows Terminal uses Ctrl+C to abort the current process (as we'd expect) when nothing is selected, but copies when there is a selection. Similarly, Ctrl+V just pastes. So convenient!