Back to Developer
Vigenère Cipher encode / decode

Vigenère Cipher encode / decode

Encode and decode with the Vigenère cipher, the classic polyalphabetic substitution from the 16th century — a repeating key (e.g. LEMON) shifts each plaintext letter. Mode toggle, preserve-case and pass-through-non-alpha options, plus an aligned plaintext / key / ciphertext view that's great for learning. Used heavily in CTFs and cryptography lessons as the next step up from Caesar.

How to use

Pick a direction (plain → cipher or cipher → plain), type your text and a **key**, and the tool runs the Vigenère transformation. Classic example: plaintext **ATTACKATDAWN** with key **LEMON** → **LXFOPVEFRNHR**. The key uses letters only (we strip any other characters automatically); both cases are accepted. **Preserve case** keeps the input's letter casing. **Pass through non-alpha** keeps spaces, punctuation, and digits untouched in the output. The **alignment table** below stacks plaintext, key stream, and ciphertext column-by-column — handy for teaching what shift was applied at each position.

In depth

What goes into a Vigenère tool and why it matters

A Vigenère cipher tool takes two inputs: plaintext (or ciphertext) and a key. In most real-world usage — CTF challenges, cryptography courses, crypto-history demonstrations — neither the text nor the key is particularly sensitive on its own. However, teams that use Vigenère tools to reconstruct or audit legacy systems may feed in actual internal codes, identifiers, or old passphrases. The key field in particular deserves attention: if the key being tested was ever used as a real passphrase in a production context, submitting it to an online tool transfers that passphrase to a third-party server.

Vigenère should never be used to protect live data — it provides no security against modern cryptanalysis. The concern here is narrower: even for historical or educational purposes, the combination of text plus key entered into an online tool is logged server-side, and that combination is more identifiable than either value alone.

Online classical cipher tools and analytics collection

Classical cipher pages are popular SEO targets in the cryptography education space. Many are instrumented with standard analytics SDKs that capture input field events. A key string typed into a Vigenère page may be collected as a form-interaction event and associated with your session, IP address, and referrer. This is the same risk that affects any online utility page with analytics — the difference is that the perceived sensitivity of a ‘historical cipher’ tool is lower, which means users are less guarded about what they type.

For CTF use: the challenge text is usually public, but intermediate decode attempts and candidate key strings from team brainstorming are not. Submitting those to a logged online service before the competition closes hands that working material to the service operator.

Letter-shift arithmetic as the complete computation

The Vigenère transform is C[i] = (P[i] + K[i mod len(K)]) mod 26 for encode and P[i] = (C[i] − K[i mod len(K)] + 26) mod 26 for decode, where A=0 through Z=25. This tool implements both directions with pure JavaScript arithmetic — String.prototype.charCodeAt() to extract the ASCII code, subtraction of the A or a offset (65 or 97) to normalise to 0–25, the modular addition or subtraction, and re-addition of the offset to form the output character code. Non-alpha pass-through is a simple charCodeAt() \< 65 || > 90 range check (adjusted for lowercase). The alignment table maps each input letter, key stream letter, and output letter into a column-by-column array rendered directly to the DOM.

No cryptographic library (crypto.subtle, libsodium, or similar) is used. No network request is made. The encode and decode results are available synchronously, in the same event loop tick as the input change.

CTF, cryptography education, and legacy audit use cases

The alignment table is the feature that makes this tool most useful for teaching. It shows, column by column, which key character was applied at each position — making the repeating key period visually obvious and providing an intuitive basis for explaining the Kasiski examination (repeated plaintext sequences produce repeated ciphertext at intervals that are multiples of the key length) and the Index of Coincidence approach used in Friedman’s test. Both attacks become concrete once learners can see the key stream laid out against the ciphertext.

For legacy system auditing: some old internal tools used Vigenère or Caesar ciphers as lightweight obfuscation (not security) for configuration values. Reconstructing what a known ciphertext decodes to under a suspected key is a legitimate debugging step. The critical caveat from the FAQ bears repeating here: Vigenère meets none of the requirements of modern cryptography — no IND-CPA security, no authentication, no protection against frequency analysis. Any live data protection must use a current cipher (AES-256-GCM, ChaCha20-Poly1305).

The tabula recta and “le chiffre indéchiffrable” history

The Vigenère cipher was invented in 1553 by Giovan Battista Bellaso, but later misattributed to Blaise de Vigenère, whose name stuck. The central tool is the tabula recta (Vigenère square): a 26×26 alphabet table where each row is the previous row shifted by one letter. Encryption is performed by looking up the row indexed by the plaintext letter and the column indexed by the key letter — algebraically equivalent to C[i] = (P[i] + K[i mod len(K)]) mod 26.

For nearly three centuries the cipher was called le chiffre indéchiffrable (“the unbreakable cipher”) because it appeared to defeat the frequency analysis that broke single-letter substitution ciphers like Caesar. The mythology collapsed in 1863 when Friedrich Kasiski published his method (Kasiski examination) for estimating key length, and was further dismantled when American cryptographer William Friedman developed the statistical Index of Coincidence approach in the early 20th century. This tool’s alignment table makes the Kasiski observation visible: when a plaintext segment repeats and aligns with the same key offset, the resulting ciphertext segment repeats too, giving away the key length.

Classical vs modern ciphers — key space, known-plaintext attacks, and the OTP exception

The Vigenère key space is 26^L for a key of length L. A five-letter key (LEMON) yields 11,881,376 possibilities, which a modern GPU can brute-force in well under a second. Even a ten-letter key gives 1.4 × 10^14 keys, exhaustible in hours on commodity hardware. AES-128, by contrast, has a 2^128 key space (3.4 × 10^38) — beyond any feasible search. Increasing Vigenère’s key length raises the brute-force cost linearly but does not defend against statistical attacks like Kasiski and Friedman, whose computational cost scales linearly with key length rather than exponentially. No length of Vigenère key buys real security.

The single exception is the One-Time Pad (OTP): when the key is (1) truly random, (2) the same length as the plaintext, (3) never reused, and (4) kept completely secret, Vigenère with that key achieves Shannon’s information-theoretic secrecy, proven in 1949. Soviet espionage in WWII and the Moscow-Washington hotline historically used this construction. Modern ciphers like AES-GCM and ChaCha20-Poly1305 trade theoretical perfection for practical strength: short keys with computational security, authenticated encryption (AEAD) for integrity, and parallelisable block or stream structure. Understanding the gap between Vigenère and these modern primitives is the most valuable takeaway from studying classical cryptography — the cipher is a teaching artefact, not a protection mechanism. To compare against the simpler monoalphabetic case, caesar-cipher handles the single-shift variant in the browser, and when CTF puzzles layer a Vigenère output inside a Base64 wrapper, base64 unwraps the outer encoding so the decoded bytes can be fed back here.

FAQ

Is my input uploaded?
No. Everything runs in your browser — letter-shift arithmetic only.
What's the Vigenère formula?
**Encode**: `C[i] = (P[i] + K[i mod len(K)]) mod 26` (A=0, B=1, ..., Z=25). **Decode**: `P[i] = (C[i] − K[i mod len(K)] + 26) mod 26`. If the key is shorter than the plaintext, repeat it. E.g. plaintext ATTACKATDAWN with key LEMON becomes LEMONLEMONLE — shift letter by letter.
How does it differ from Caesar?
**Caesar** shifts every letter by the same amount (A→D, B→E …). **Vigenère** shifts each position by a different amount, so frequency analysis is much weaker. Still breakable via Kasiski or Friedman analysis once you guess the key length — never use this for real security.
How long should the key be?
For classic-cipher fun, **5–10 letters** is a sweet spot — long enough to obscure the period but short enough to be memorable. Do **not** use it for real cryptography: it doesn't meet any modern requirement (128-bit keys, IND-CPA / IND-CCA2 security). This tool is for teaching, CTFs, and crypto history.
How are non-letter characters handled?
With **Pass through non-alpha** on (default), spaces / digits / punctuation / non-Latin scripts pass through verbatim (`Hello, World!` + key `key` → `Rijvs, Uyvjn!`). Off, they're stripped and you get an alphabet-only ciphertext — useful in CTFs where spaces would leak the key period.
What if I leave the key empty?
An empty key (or one with no letters after normalisation) reduces to a zero shift, so the input passes through unchanged. The tool flags this and asks you to provide a real key.
Where does this cipher come from?
The Italian **Giovan Battista Bellaso** designed it in the 16th century; it was later named after **Blaise de Vigenère**, who didn't actually invent it. It was famously called *le chiffre indéchiffrable* (the unbreakable cipher) for centuries — until **Friedrich Kasiski** published his break in 1863.

How to verify nothing is uploaded

This tool never sends your input outside your browser. The pages below explain how it works, how to audit it, and how the site is run.

Related tools