Guide · 2FA recovery code formats
There is no universal standard for what a 2FA recovery code looks like. Each service picks its own style — but the choices cluster around a few familiar patterns. Understanding them helps you recognize real backup codes, design better 2FA interfaces, and generate realistic test data with the ReKey generator.
Character sets: numeric vs alphanumeric
The two common families are:
- Numeric codes — digits 0–9 only, e.g.
4821 9034. Easy to type on any phone keypad without switching keyboard layouts. Because each position carries little information, numeric codes need to be longer to reach the same strength. - Alphanumeric codes — uppercase letters plus digits (A–Z, 0–9), e.g.
XK7Q-9M2P. Each character carries more possibilities, so the code can be shorter. Some services use mixed case (A–Z, a–z, 0–9) for even more density.
A thoughtful detail you will see in careful designs: excluding ambiguous characters. The digit 0 and the letter O, or the digit 1 and the letter I, look identical in many fonts — a real problem when someone is transcribing a code from a printed sheet under stress. Some systems drop those characters from the alphabet entirely.
Grouping: why the dashes exist
Long unbroken strings are hard for humans to copy accurately. That is why most backup codes are split into groups of four separated by dashes or spaces — XXXX-XXXX for 8 characters, XXXX-XXXX-XXXX for 12. Grouping exploits "chunking": human short-term memory handles a few short chunks far better than one long string.
The dashes carry no security meaning — the service strips them before checking. They are pure ergonomics, reducing transcription errors when a user reads a code off paper and types it into a form.
Length and entropy: what the numbers mean
A code's guessing resistance is measured in bits of entropy: each additional bit doubles the number of possible codes. The formula is simple — length × log₂(alphabet size). Here is what common formats actually carry:
| Format | Example shape | Entropy | Possible codes |
|---|---|---|---|
| 8 numeric | 48219034 | ~27 bits | 100 million |
| 10 numeric | 4821-9034-17 | ~33 bits | 10 billion |
| 8 alphanumeric (A–Z, 0–9) | XK7Q-9M2P | ~41 bits | ~2.8 trillion |
| 10 alphanumeric (A–Z, 0–9) | XK7Q-9M2P-4R | ~52 bits | ~3.7 quadrillion |
| 12 alphanumeric (A–Z, 0–9) | XK7Q-9M2P-4RTW | ~62 bits | ~4.7 × 10¹⁸ |
| 16 mixed case (A–Z, a–z, 0–9) | Xk7Q-9m2P-4RtW-z8Nd | ~95 bits | ~4.8 × 10²⁸ |
A few things this table tells you:
- An 8-character alphanumeric code (~41 bits) is far harder to guess than an 8-digit numeric code (~27 bits) — the alphabet matters as much as the length.
- Backup codes do not need password-level entropy, because they are single-use and rate-limited: after a handful of wrong guesses, a sane service locks the attempt path. The format mainly needs to resist casual guessing, not nation-state brute force.
- Longer is not always better for users. Sixteen mixed-case characters are painful to transcribe from paper — which is exactly why most real services settle around 8–10 characters.
What real services tend to do
Formats vary, but the center of gravity is clear: a set of roughly 8–10 codes, each 8–10 characters, alphanumeric or numeric, often grouped in fours. That combination balances typing effort, readability on a printed page, and more than enough entropy for a single-use, rate-limited credential.
If you are designing a 2FA flow yourself, copy the ergonomics — grouped, unambiguous characters, one-time use with server-side invalidation — not just the look.
Try it: the ReKey generator lets you switch between numeric, uppercase alphanumeric and mixed-case sets at 8, 10, 12 or 16 characters, with or without XXXX grouping — and shows the entropy of each combination as you generate.
Next: where these codes are actually useful
Testing 2FA interfaces, writing documentation, building demos — legitimate use cases for generated recovery codes.
Legitimate use cases