A 4 rail fence cipher decoder reconstructs text that was scrambled by writing characters diagonally across four rows and reading each row back in order. The rail pattern for four rows goes 0, 1, 2, 3, 2, 1 and then repeats, giving a full cycle of six positions before the zigzag starts over. To decode, a tool counts how many characters belong to each rail, slices the ciphertext into those four buckets, and consumes one character from the correct rail for each position of the original message. The original ordering is restored exactly when the same rail count and conventions are used in both directions. The Rail Fence Cipher Decoder runs that whole reconstruction locally in your browser, so the plaintext never leaves the device and the cycle math is applied without any guessing about rail counts.
Rail Fence is a transposition cipher, which is the family that includes the scytale and columnar routes. Nothing about it is secret beyond the rail count. The single piece of information a recipient needs to undo the zigzag is the same rail count the sender used, and small numbers like 2, 3, 4 or 5 are trivial to try by hand. That makes Rail Fence excellent for teaching the idea of position-based scrambling but unsuitable for any real-world confidentiality, which the section near the end of this page addresses directly.
The 4-Rail Zigzag Has a Cycle of Six
Every Rail Fence configuration is described by a repeating row pattern. For r rails that pattern is the sequence 0, 1, 2, …, r−1, r−2, …, 2, 1. For four rails it becomes 0, 1, 2, 3, 2, 1, and the cycle length is 2·(r−1), which works out to six positions. After the sixth character the row counter resets to 0 and the descent starts again.
Layout of a short message written down a four-rail zigzag, with the original position numbers shown:
- Row 0 (top): original positions 0, 6, 12, 18, …
- Row 1: positions 1, 5, 7, 11, 13, 17, …
- Row 2: positions 2, 4, 8, 10, 14, 16, …
- Row 3 (bottom): positions 3, 9, 15, 21, …
That structure is what makes decoding deterministic. Given the ciphertext and the rail count, a decoder can compute exactly how many characters belong to each row, split the ciphertext in those proportions, and then walk the same zigzag to put every character back where it started. No padding is invented and no row count is guessed: the row sizes are forced by the rail count and the length of the message.
How to Decode a 4-Rail Fence Cipher in Your Browser
- Open the Rail Fence Cipher Decoder page and pick Decrypt as the mode.
- Type 4 in the rails field. The tool validates that the value is a whole number between 2 and 100; 4 sits comfortably inside that range.
- Paste the ciphertext into the input box exactly as it was given to you. Keep every space, period, comma, line break and emoji, because each one is treated as a separate code point that participates in the zigzag.
- Click Run. Internally the decoder counts how many positions of the input fall on each of the four rails, slices the ciphertext into four row buckets of the right sizes, and consumes one character from the matching bucket for every position of the original message.
- Copy the result from the output block without trimming whitespace, and use the same rail count to send a reply if you want the conversation to round-trip cleanly.
- If the plaintext still looks scrambled, double-check that you used 4 rails, that the sender started at the top rail with no offset, and that the ciphertext was not stripped of spaces before it reached you. Different conventions are the most common reason two Rail Fence tools disagree on the same ciphertext.
A Worked 4-Rail Example: ABCDEFGHIJKL
Take the twelve-character message ABCDEFGHIJKL and write it down the four-rail zigzag, marking each row:
- Row 0: A _ _ _ _ _ G _ _ _ _
- Row 1: _ B _ _ _ F _ H _ _ L
- Row 2: _ _ C _ E _ _ _ I _ K _
- Row 3: _ _ _ D _ _ _ _ _ J _
Encryption reads row 0 left to right, then row 1, then row 2, then row 3, and concatenates them. Row 0 gives A + G = AG, row 1 gives B + F + H + L = BFLH, row 2 gives C + E + I + K = CEIK, row 3 gives D + J = DJ. The full ciphertext is AGBFLHCEIKDJ, still twelve characters.
Now run the decoder on AGBFLHCEIKDJ with four rails. The first step counts the four rail sizes by simulating the zigzag on twelve positions, giving 2 + 4 + 4 + 2. The ciphertext is sliced into those four buckets in order: AG, BFLH, CEIK, DJ. The decoder then walks positions 0 through 11, looks up the row for each position (0, 1, 2, 3, 2, 1, 0, 1, 2, 3, 2, 1), and pulls one character from the head of the corresponding bucket:
- Position 0, row 0 → A from AG
- Position 1, row 1 → B from BFLH
- Position 2, row 2 → C from CEIK
- Position 3, row 3 → D from DJ
- Position 4, row 2 → E from CEIK
- Position 5, row 1 → F from BFLH
- Position 6, row 0 → G from AG
- Position 7, row 1 → H from BFLH
- Position 8, row 2 → I from CEIK
- Position 9, row 3 → J from DJ
- Position 10, row 2 → K from CEIK
- Position 11, row 1 → L from BFLH
The reconstructed plaintext is ABCDEFGHIJKL, which matches the original character for character. That round trip is confirmation only that the conventions agree; it tells you nothing about confidentiality.
Why Two 4-Rail Decoders Can Disagree
If you paste the same ciphertext into a different Rail Fence tool and get different plaintext, the most likely causes are convention differences rather than bugs. The Rail Fence Cipher Decoder implements the most standard convention: no initial offset, start at the top rail, move downward first, and preserve every code point exactly. Other implementations may strip spaces and punctuation, start from the bottom rail, reverse the direction, or apply an offset that shifts the row counter before the first character. Even a one-position offset scrambles every downstream row assignment, so the output looks completely unrelated to the offset-free result.
Because the rail count is the only secret, anyone with a candidate ciphertext and a Rail Fence decoder can try 2, 3, 4, 5 and so on by hand. The Rail Fence Cipher Decoder deliberately does not guess a rail count for you; it asks you to specify one and rejects anything outside the 2 to 100 range as a separate failure rather than silently defaulting. If a puzzle expects you to find the rail count, treat that as a separate cryptanalysis step. Comparing output against another reference implementation, such as the dCode Rail Fence page, is a useful way to spot a convention mismatch.
For more on lining up conventions between sender and receiver, see How to Decipher a Rail Fence Cipher: Match the Convention.
Rail Counts at a Glance
The cycle length for any rail count r is exactly 2·(r−1). The table below summarises the cycles for the rail counts a teacher or puzzle is most likely to set. Larger rail counts have longer cycles and therefore require longer messages before the zigzag pattern repeats.
| Rail count | Row pattern (one cycle) | Cycle length | Where it shows up |
|---|---|---|---|
| 2 | 0, 1 | 2 | The simplest transposition; equivalent to taking every other character. |
| 3 | 0, 1, 2, 1 | 4 | The canonical teaching example, including the well-known WEAREDISCOVEREDFLEEATONCE phrase. |
| 4 | 0, 1, 2, 3, 2, 1 | 6 | Common in classroom worksheets and online puzzles, and the focus of this page. |
| 5 | 0, 1, 2, 3, 4, 3, 2, 1 | 8 | Just enough complexity that brute force takes a few extra steps. |
| 6 | 0, 1, 2, 3, 4, 5, 4, 3, 2, 1 | 10 | Often used to introduce variable rail counts in beginner cryptography lessons. |
| 7 and up | Pattern grows symmetrically | 2·(r−1) | Supported by the decoder up to 100 rails, but mostly seen in advanced puzzles. |
Remember that the rail count must be a whole number between 2 and 100 and that input is capped at 200,000 code points so the row construction stays responsive. Inputs longer than that should be split or simplified before decoding.
Rail Fence Is a Teaching Cipher, Not Real Security
Rail Fence does not change any character. It only rearranges them, which means every letter frequency in the plaintext survives into the ciphertext intact. That property alone is enough for a cryptanalyst to confirm a candidate plaintext the moment the character histogram lines up with English (or any other known language). Combined with a brute-forceable key space of at most 99 rail counts, Rail Fence offers essentially zero confidentiality.
The Rail Fence Cipher Decoder is built for learning, puzzles, classroom demonstrations, and reconstructing historical ciphertexts where the rail count is already known. It is not appropriate for credentials, personal data, tokens, files, or any other communication that needs to stay private. For those cases, a reviewed authenticated-encryption construction such as AES-GCM is the appropriate tool, and the Rail Fence decoder should be reserved for its teaching role.
Even within a teaching context, the deterministic nature of the cipher is worth keeping in mind: identical input and rail count always produce identical output, and a successful encrypt/decrypt round trip confirms only that the conventions match, not that the message is secret. Treating that round trip as proof of confidentiality is one of the most common beginner mistakes in classical cipher study.
If you're weighing options, ROT13 Decoder API Alternative: Run It Locally in Browser covers this in detail.