Which standards CipherPad follows

Last updated: 15 October 2026

Why this page exists

If you decode a message here and get a different answer from another site, one of two things has happened: one implementation is wrong, or the two implement different variants. The second is far more common, and it is impossible to tell which without knowing what each tool actually does. So this page states, for each translator, which standard or variant is implemented and how the awkward cases are handled.

The descriptions below were read off the implementation, not written from intention. Where something is a deliberate simplification, it says so. Where a variant is not supported, it says that too, rather than leaving you to discover it from a wrong answer.

Standards and edge cases by translator

Test vectors, computed by the engine

Each row below is the worked example a translator opens with, run through the same engine function the translator uses, with the key a fresh translator starts with. The table is generated when the site is built, so nothing in it is typed by hand: if an engine changed, this table would change with it. The last column runs the output back through the decoder to show whether the round trip is exact.

The leetspeak row is lossy by design, not by accident: 1 stands for both i and l, and the decoder reads it as i. No decoder can know which letter was meant, so it picks one and says so here.

How the code breakers score keys

The Caesar Cipher, Affine Cipher, Rail Fence Cipher and Vigenere Cipher translators can recover the key from the ciphertext alone. Each one searches the possible keys, scores the decoded text, and shows the best candidates with their score and what the score measures. Two rules keep the result honest:

• A minimum length.Below a minimum number of letters the right key stops winning reliably, so a shorter text gets "not enough text" instead of a winner. The minimums below were measured on English test sentences enciphered by the engine.
• Two signals before "Solved". A candidate is only marked as solved when the statistic the keys were ranked by and a second, independent check agree. Keys ranked by letter frequency must also read as English letter order, and keys ranked by readability must also have English letter frequencies.

Two measures are used. Chi-squared compares the decoded letter frequencies with English (lower is better), which works for ciphers that replace letters. Rail fence only reorders letters, so its letter frequencies are identical for every key and cannot rank them: it is ranked by a readability heuristic instead, which counts common English letter pairs, letter triples and common words (roughly 0 to 100, higher is better). That heuristic is a rule of thumb built into the code, not a published dataset. Only the first 2,000 characters of a message are scored; statistics settle long before that.

The table runs each code breaker on its translator's longer worked example, enciphered with the default key, at build time.

How these numbers are checked

Two automated checks run against the code before a change ships. The test suite (npm test) enciphers English test sentences with known keys and fails unless each code breaker puts the right key first, is never marked solved on a wrong key, and answers "not enough text" below its minimum. It also checks that the homepage turns one word into all 21 outputs and decodes Caesar, Atbash, ROT13, Morse and binary test messages back to the plain text. The post-build check (npm run verify) recomputes every test vector and code breaker result on this page from the engine and fails the build if the page shows anything else.

Rules that apply everywhere

• Nothing is uploaded. Every translator runs in your browser. See the privacy policy for how to verify that in the Network tab.
• Unsupported characters are handled predictably, not silently corrected. Each translator either drops a character it cannot map or passes it through unchanged, and the table above says which. Neither behaviour is universally right, so the rule is to be consistent and to document it.
• Nothing here is secure. Every scheme on this site is an encoding or a broken historical cipher. Each translator carries a permanent notice explaining which of the two it is. For real protection, use vetted modern cryptography such as the Web Crypto API.
• Encoding and encryption are kept apart. Morse, binary, braille, Base64, NATO and A1Z26 are encodings: public, keyless and concealing nothing. Only the schemes grouped as ciphers attempt concealment, and all of them fail at it.

When this changes

If a translator's behaviour changes, this page and the changelog are updated in the same change. If you find a case where the behaviour here does not match the table above, that is a bug worth reporting through the contact page.