Colemak vs Dvorak vs QWERTY: which to pick

The short answer

The Colemak vs Dvorak vs QWERTY question has a dull answer for most people: stay on QWERTY, because the cost is paid in weeks of slow work and the benefit is small and hard to measure. If you do want to move, Colemak is the cheaper move. It leaves 13 of the 30 letter and punctuation keys exactly where QWERTY has them, and it keeps the copy and paste keys in place. Dvorak is the more disruptive move with the widest support, since every mainstream operating system has shipped it for decades. Neither layout will make you a faster typist on its own. What they change is how far your fingers travel, and how that feels at the end of a long day.

This page is the decision. If you have already made it and you want the commands, go to the Colemak setup guide for Linux.

What each layout was designed to do

QWERTY comes from the Sholes and Glidden typewriter of the 1870s, and its goal was mechanical. On that machine every key swung a metal typebar up from a basket to strike the paper, and two bars sitting close together could clash and jam if they were struck in quick succession. Spreading common letter pairs apart reduced the jams. The popular claim that QWERTY was designed to slow typists down is a distorted version of that story. Historians have also traced parts of the arrangement to telegraph operators transcribing Morse code. The part that matters to you is simple: the layout was frozen by 1878 hardware, then locked in by decades of training, and no part of it was tuned for a keyboard with no moving parts.

Dvorak is the 1936 alternative from August Dvorak and William Dealey. Its design rule is visible in the layout itself. All five vowels sit on the left home row, AOEUI, and the most common English consonants sit on the right home row, DHTNS. Common words then alternate between the hands, and the strongest fingers do most of the work. It is also the most disruptive of the three by a wide margin, because only two keys, A and M, keep their QWERTY positions.

Colemak was published by Shai Coleman in 2006, and its design constraint was the switching cost itself. The home row reads A R S T D on the left and H N E I O on the right, which puts the most common English letters under the fingers, while everything else moves as little as possible. The bottom row keeps Z X C V B where QWERTY has them. Colemak also remaps Caps Lock to Backspace, which is a separate habit you can adopt on any layout or ignore entirely.

Colemak vs Dvorak vs QWERTY: how many keys actually move

Count the three letter rows, which hold 26 letters and 4 punctuation keys, and compare each layout against QWERTY position by position. The shortcut column counts how many of Z, X, C and V stay in their QWERTY places, since those four carry undo, cut, copy and paste on most systems.

[
  {
    "label": "QWERTY",
    "keys_moved_from_qwerty": 0,
    "shortcut_keys_kept": 4
  },
  {
    "label": "Colemak",
    "keys_moved_from_qwerty": 17,
    "shortcut_keys_kept": 4
  },
  {
    "label": "Dvorak",
    "keys_moved_from_qwerty": 28,
    "shortcut_keys_kept": 0
  }
]

Colemak moves 17 keys. Dvorak moves 28. That gap is the whole practical difference between the two. Every moved key is one habit you have to unlearn while your hand keeps reaching for the old place, so the count is a rough measure of how long the painful part lasts. It says nothing about which arrangement is better.

Do the editing shortcuts stay where you expect?

Colemak keeps Z, X, C and V in their QWERTY positions, so Ctrl+Z, Ctrl+X, Ctrl+C and Ctrl+V stay under the same fingers on the same hand. Dvorak keeps 0 of them. On Dvorak the letter C sits where QWERTY prints I, V sits on the QWERTY full stop key, X sits under the QWERTY B, and Z sits on the QWERTY slash key. Copy and paste become a two hand reach.

This matters more in a terminal than in a word processor. Ctrl+C to interrupt a running command and Ctrl+D to close standard input are things a server operator presses hundreds of times a day, and on Dvorak both move to the right hand: C to the QWERTY I key, D to the QWERTY H key. macOS ships a variant that reverts to QWERTY while the Command key is held. Linux has no standard equivalent for the Ctrl key, so on Dvorak the shortcuts move and they stay moved.

Vim and less move the cursor with h, j, k and l, and those letters were chosen because they sit under the right hand on QWERTY. Both alternative layouts break that. On Colemak, the letters printed on the physical QWERTY h, j, k and l keys are h, n, e and i, and the usual fix is to remap movement to those four. On Dvorak the same four physical keys type d, h, t and n. Either fix is a few lines in your vimrc, and it stops helping the moment you are on someone else's machine with a stock config.

Where the typing speed evidence is weak

Part of the argument is arithmetic and is not in dispute. Given a layout and a body of text, you can compute the total distance the fingers travel and how often one finger has to type two letters in a row. Both numbers are lower on Dvorak and Colemak than on QWERTY for ordinary English prose, and the layout analysers agree on the direction. Those results depend on the text they were computed from, though. Your source code, your language and your variable names are not that text.

The disputed part is whether the arithmetic turns into speed. The strongest claim for Dvorak comes from a United States Navy study during the Second World War that reported large gains from retraining. That study was run under August Dvorak's own supervision, so it is not independent evidence. In 1956 Earle Strong ran a controlled retraining study for the General Services Administration and found that Dvorak retraining did not beat giving the same extra practice to QWERTY typists. In 1990 the economists Stan Liebowitz and Stephen Margolis collected these criticisms in a paper called The Fable of the Keys, and that paper is argued over in turn, because its real subject is market lock in rather than keyboards. After ninety years there is still no large, well controlled trial showing that an alternative layout makes people type faster.

There is a simpler reason to be careful with speed claims. People have typed well past 150 words per minute on QWERTY. If you type at 60 or 70, the thing limiting you is not the layout.

Comfort and injury are a harder question with even less evidence. People do report that their hands hurt less after switching, and that is worth taking seriously, but a switcher usually changes several things at once. A new keyboard, a different desk height, more breaks, and several weeks of deliberately slow typing all arrive in the same month, and any of them could be the cause. If pain is your reason, fix your posture and your workload first, because those have better evidence behind them and they cost nothing.

What switching really costs

Expect to type like a beginner for the first few days, somewhere near 15 words per minute, and to spend two to four weeks before the layout stops taking all of your attention. Getting back to your old speed commonly takes one to three months of daily use. These are the figures people who did it report, not the output of a study, so treat them as a range rather than a promise.

The part that surprises people is interference. Your hands do not learn "Colemak". They learn one destination per key, and using two layouts on alternate hours keeps both mappings weak. Switching back to QWERTY for an urgent task and then switching again is the slowest possible way to learn. Two approaches work. Switch once and accept the bad week. Or keep a hard split, where one physical keyboard is always one layout, so the context tells your hands which mapping to load.

Most people who give up do so during that dip, and they give up because the week was busy, not because the layout was wrong for them. That makes timing the most important decision in the whole switch. Start on a quiet week. Do not start the week before a deadline, and do not start the week you are on call.

Your QWERTY skill usually survives. Most switchers report it returns within a few days of use, slower than before and with mistakes at first. That is worth knowing, because losing it is the thing people fear most and it is the part that turns out to be least true.

Client or server: where does a remap belong?

Almost always the client. A keyboard layout is applied on the machine the keyboard is attached to, and nowhere else. When you press a key, your local system turns that key position into a character, and the SSH session that carries your keystrokes sends the character to the server as a byte. The server never sees a key press. So running localectl set-keymap dvorak on a remote box changes nothing about how your typing arrives over SSH, and a workstation set to Colemak types Colemak into every host you log into, with no configuration on any of them.

The server's own keymap matters in two places: a keyboard physically attached to the machine, and a console your provider gives you in a browser or over a serial link. On a VPS that means the rescue console, which is exactly the situation where you can least afford to experiment.

localectl status
localectl list-keymaps | grep -i dvorak

localectl status prints both settings: VC Keymap for the text console and X11 Layout for a graphical session. list-keymaps prints the console keymap names your system actually has installed, which is the check that stops you setting a name that does not exist. Colemak is not always present as a console keymap even when it is available for the graphical session, so run that grep for your own layout before you assume it is there.

On the desktop side, setxkbmap -layout us -variant colemak changes the layout of a running X session, and localectl set-x11-keymap us pc105 colemak makes the choice survive a reboot. Under Wayland the compositor owns the keymap, so setxkbmap is the wrong tool there and the change belongs in your desktop's input settings or in localectl. The full procedure, including what to do with Caps Lock, is in the Colemak on Linux walkthrough.

Why keyboard firmware sidesteps the whole problem

If you log into many machines, put the layout in the keyboard instead of in the operating systems. A programmable keyboard stores its own mapping and sends the code for the letter you want, so every host sees an ordinary keyboard typing ordinary letters. Nothing on any host needs configuring, and nothing can be forgotten on a rebuild. That also covers the machines you cannot configure at all: a colleague's laptop, a UEFI setup screen, a rescue image, or a host where you have no right to change system settings. For anyone who has to keep dozens of Linux servers in order, this is the difference between one purchase and a configuration item on every box.

The common route is a keyboard running QMK, or its wireless relative ZMK, both of which are open firmware you flash yourself, with VIA and Vial as graphical editors that write a change without a rebuild. Many mainstream keyboards also ship vendor software that stores a remap in the keyboard. The limits are honest ones. A laptop's built in keyboard usually cannot do this, so you get your layout when the external keyboard is plugged in and QWERTY when it is not, which is its own kind of interference.

The rescue console is a real operational risk

The failure looks like this. A server does not come back from a reboot, you open the provider's web console, and you have to type a root password and a few filesystem commands with a layout you no longer type well. Two things can go wrong at the same time. Your muscle memory is now the new layout, and the console may not honour it.

Browser consoles differ in what they send. Some forward the character your local system produced, in which case your client side remap follows you. Others forward the key position and assume a US QWERTY map on the far side, in which case your Colemak keyboard types QWERTY letters into the console. You cannot tell which kind you have by reading the control panel. Test it while the machine is healthy: open the console, log in, type a sentence, and look at what appears. Do that now, not during an outage.

Then remove the parts you can. Log in with keys so that ordinary access never asks you to type a password, and treat key management across your servers as part of the recovery plan rather than a convenience. Keep the rescue password somewhere you can paste from, because most browser consoles have a send text or paste function. And keep some ability to find QWERTY letters by looking at the keyboard, because reading a layout chart off your phone at two in the morning is slow.

Encrypted disks add one more trap. The passphrase prompt at boot runs from the initial ram disk, before your normal keymap is loaded, so it uses whatever map was built into that image. On Debian and Ubuntu that is the built in US QWERTY map by default. The setting is KEYMAP= in /etc/initramfs-tools/initramfs.conf, and it ships as n. Set it to y, run sudo update-initramfs -u, then reboot and confirm the passphrase prompt takes your layout before you trust it. A machine that will not unlock is a machine you have to rebuild.

Colemak-DH and the rest of the field

The choice is not three options. Colemak-DH, also called Mod-DH, is the most common refinement of Colemak. On standard Colemak the letters D and H sit in the middle columns of the home row, which the index fingers reach by stretching sideways rather than by curling. Mod-DH moves those two letters down to the bottom row under the index finger, giving a home row of A R S T G on the left and M N E I O on the right. There are two versions, one for the usual row staggered keyboards and one for ortholinear and column staggered boards, and you want the one that matches your hardware.

Beyond that sit Workman, Norman, Canary, Graphite and many more designs produced by layout optimisers. Programmer Dvorak rearranges the number row and the symbols for people who type more punctuation than prose. Other languages have their own answers, such as bépo for French and Neo for German. The practical filter is availability. Dvorak ships almost everywhere, including phone keyboards and console keymaps. Colemak ships with the X keyboard configuration data that every Linux desktop reads. Colemak-DH arrived in that data more recently, so on an older distribution you may still have to install the layout files from the project. A community layout is a file you have to carry to every machine, or bake into your keyboard firmware.

So which one should you pick?

Stay on QWERTY if nothing is wrong. The switch costs weeks, and the evidence that you gain speed is weak, so mild irritation with your current layout is not a strong enough reason on its own.

Choose Colemak if you want the rearrangement at the lowest cost. Thirteen keys stay put, the editing shortcuts stay put, and it is a one line change on any Linux desktop.

Choose Dvorak if you value being able to set your layout from a menu that is already present on any machine and any operating system, and you accept relearning the shortcut keys.

Choose Colemak-DH if you are already buying a programmable keyboard. The firmware removes the availability problem, so you may as well take the refinement.

Whatever you pick, decide where the mapping lives before you start. If you spend the day in a full time terminal workbench and you log into a lot of machines, the keyboard is the right place for it. If you work on one laptop, the operating system is fine. Then plan the rescue path, and test it before you need it.

FAQ

Is Colemak or Dvorak actually faster than QWERTY?

There is no good evidence that either one makes you type faster. What can be measured is the arithmetic: for English prose, both put more keystrokes on the home row and make the fingers travel less than QWERTY does. What has never been shown by a large, well controlled trial is that this produces higher words per minute. The Navy study most often quoted for Dvorak was supervised by Dvorak himself, and Earle Strong's 1956 study for the General Services Administration found no advantage once QWERTY typists were given the same extra practice. People reach well past 150 words per minute on QWERTY, so if you type at 70, the layout is not your limit.

How long does it take to learn a new keyboard layout?

Plan for a few days of typing near 15 words per minute, two to four weeks before the layout stops taking your full attention, and one to three months to reach your old speed. Those are reported ranges, not study results. The bigger risk is interference: alternating between two layouts during the day keeps both of them weak, so either switch once and accept the slow week, or keep a hard split where one physical keyboard always means one layout. Most people who quit do so during that slow period because the week got busy, so start on a quiet one.

Does my keyboard layout follow me over SSH?

Yes, and the server has no say in it. The layout is applied on the machine your keyboard is attached to. Your local system turns the key press into a character and SSH sends that character as a byte, so the remote host never sees a key position. Setting a keymap on the server changes nothing for SSH users. A server's own keymap only applies to a directly attached keyboard or to a console the provider hands you in a browser or over a serial link.

What happens to Ctrl+C and the vim h j k l keys?

Colemak leaves Z, X, C and V in their QWERTY positions, so the standard editing shortcuts do not move. Dvorak moves all four: C lands on the QWERTY I key, V on the QWERTY full stop, X under the QWERTY B, and Z on the QWERTY slash. Ctrl+D moves to the QWERTY H key, which matters in a shell. Cursor movement breaks on both layouts. Colemak users usually remap movement to h, n, e and i, which are the letters printed on the physical QWERTY h, j, k and l keys, and Dvorak users use d, h, t and n for the same reason.

How do I keep a rescue console usable after switching layouts?

Test it now, while the server is healthy. Open your provider's console, log in and type a sentence, because some consoles forward the character your client produced and others forward the key position and assume US QWERTY on the far side. Log in with SSH keys so routine access never needs a typed password, and keep any rescue password somewhere you can paste from, since most browser consoles have a paste or send text function. If the disk is encrypted, the boot passphrase prompt uses the keymap built into the initial ram disk. On Debian and Ubuntu that means setting KEYMAP=y in /etc/initramfs-tools/initramfs.conf, running sudo update-initramfs -u, and then rebooting to confirm the prompt accepts your layout.