Cipher Identifier
Cipher identifier lists candidates from explicit text features and explains every match; it does not determine the cipher, crack a message or supply accurate plaintext.
Ready. Matches are alternatives, not conclusions.
Original controlled feature checks
We created eight samples with known operations and reversed them using the known settings before running the feature rules. The original and generated sample are recorded below. Each expected candidate was included. This confirms that a rule can match a controlled example; it does not prove identification accuracy on unknown messages. Other candidates can match the same sample.
| Our controlled operation | Original | Generated sample | Known reverse check | Feature candidate included |
|---|---|---|---|---|
| Controlled Caesar shift 3 | HELLO | KHOOR | HELLO | Caesar / ROT13 |
| Controlled Bacon 26 | AB | AAAAA AAAAB | AB | Literal Bacon A/B groups |
| Controlled written Morse | SOS | ... --- ... | SOS | Written Morse-like notation |
| Controlled binary byte | A | 01000001 | A | Eight-bit binary representation |
| Controlled Playfair, ABCDE key | AB | BC | AB | Playfair under this site’s I/J convention |
| Controlled hex byte | I | 49 | I | Hex byte representation |
| Controlled Base64 byte | A | QQ== | A | Padded-length Base64-like representation |
| Controlled URL-safe bytes | ff0000 | _wAA | ff0000 | Base64url-like representation |
KHOOR contains five English letters. Our experiment created it with Caesar shift three and independently shifted it back to HELLO. Its letter shape also fits Atbash, substitution, known-key Vigenere and rail fence; the candidate tool cannot select Caesar from those alternatives. It does not use knowledge of the original experiment when analyzing the input.
The second sample has two complete A/B groups with indices zero and one. We encoded AB with the 26-letter Bacon mapping, then reversed those groups back to AB. Those same low indices also fit the 24-letter mapping, so the feature rule does not decide between alphabet versions.
The dot/dash sample was generated from our S/O mapping and restored to SOS with that known mapping. The candidate rule only checks notation shape; it does not promise every dot/dash group is a valid Morse code. The binary sample has eight zero/one digits. We calculated it from the character A, then reversed that integer to A. Its characters also satisfy even-length hexadecimal syntax. This overlap is displayed rather than hidden.
The remaining rows cover the site’s prepared Playfair pair shape and three byte-encoding syntaxes. We generated BC from AB using the ABCDE key square and reversed that known pair; generated hex 49 and Base64 QQ== from the byte for A or I as shown; and generated URL-safe _wAA from bytes ff0000. Python decoded each byte representation to the recorded original. Syntax matches remain candidates, not proof of the input’s actual origin.
To reproduce a row, paste its generated sample into the tool and inspect the stated candidate reasons. The known reverse checks belong to our controlled experiment, not to the identifier’s output. No candidate score, success rate or plaintext prediction is calculated.
Feature rules and limits
English letters allow several classical letter transformations and rail fence as candidates, with no ranking. The site’s Playfair convention additionally requires an even letter count, English letters and whitespace only, and no J. This is merely its prepared-text shape.
Literal Bacon candidates require A/B and optional whitespace or word slashes, complete five-symbol groups and assigned indices. Written Morse-like candidates require dots and dashes with separators; code validity is not certified. Binary byte candidates require zero/one digits with a length divisible by eight. Hex-byte candidates require an even number of hexadecimal digits. Base64-like candidates use only stated alphabet, length and optional trailing-padding checks; they do not validate bytes or canonical padding bits. URL-safe candidates require the URL-safe alphabet and a - or _ marker. Representations are labeled separately from classical ciphers.
Enter one text sample up to 10,000 Unicode characters. Output is a list with a concrete feature reason per candidate and one-click copy. There is no login, registration, upload, batch mode, saved history or daily counter. Processing stays in your browser. Unsupported features produce an explicit no-match message, not a claim that the sample is not a cipher.
How is this different from Cipher Decoder?
Cipher Decoder displays transformations such as Caesar shifts and known-key Vigenere results for you to inspect. This page lists feature candidates and reasons without decoding them. Neither page determines which result is correct.
Can it tell me the exact method or original message?
No. Many methods share the same alphabet and lengths, and ordinary text can satisfy encoding syntax. An unknown key, alphabet or convention is not recovered by these rules. Use controlled settings and external context yourself; the tool does not crack messages.
Individual classic tools
Caesar and ROT13, Atbash, Vigenere, Pigpen, Substitution Cipher, Bacon Cipher, Playfair and Rail Fence apply explicit operations or settings. Selecting a link does not validate a candidate.
Related controlled walkthrough
This existing walkthrough shows rail fence position rearrangement with a known rail count. It does not demonstrate identifying an unknown cipher.
Loading the player connects to YouTube and shares connection information such as your IP address and playback requests.
For possible digest families based on length and syntax, use the Hash feature candidate tool.