
Leet speak is a single, simple, completely reversible substitution cipher hiding inside what looks like slang. The Leet Speak Converter takes any string, walks it character by character against a fixed lookup table, and emits the leet equivalent — or walks it back, decoding h4ck3r to hacker. The “Basic” table is six swaps (a→4, e→3, i→1, l→!, o→0, s→5, t→7); the “Full” table adds another dozen (b→|3, k→|<, m→//, n→||, z→2); the “Caps” mode turns the same swaps loose on uppercase letters. There’s no rot-13 cleverness, no entropy trick, no language model — just a character-by-character dictionary the tool applies identically every time. Which means: if you understand those six swaps, you already understand 80% of every leet string you’ll meet.
What “leet” actually is — a one-line alphabet swap
Leet (also written 1337, l33t, “eleet”) is a non-standard orthography that replaces specific Latin letters with visually similar digits, symbols, or letter pairs. The most common substitutions map a→4, e→3, i→1, l→!, o→0, s→5, t→7. The mapping is one-to-one within the basic table: every leet glyph stands for exactly one English letter, and every English letter has at most one basic leet equivalent. That bijectivity is what makes the cipher reversible — the Leet Speak Converter decoder inverts each substitution and emits the original character when a match is found.
The style choice matters more than the alphabet itself. Basic keeps substitutions to the canonical six and stays readable even to readers who’ve never seen leet before. Full layers in dense, multi-character symbol substitutions (b→|3, k→|<, m→//, n→||, z→2) that look like ASCII art and are deliberately hard to parse at speed — the authentic “script kiddie” aesthetic from the late 1990s. Caps mode applies the same basic table to uppercase letters, which is essential when your source is HACKER and you want H4CK3R rather than H4cK3R. For quick demos the basic mode is enough; for understanding what shows up in real-world leet strings the full table is the one to learn.
The canonical 1337 alphabet at a glance
The basic table is small enough to memorize in a minute. Leet speak is not a static one-to-one substitution like a→4 and e→3 — different sources use different conventions (some swap l→1, some swap l→!), and the Leet Speak Converter defaults to l→! to keep it from colliding with i→1. The full table adds visually suggestive character pairs for letters the basic table can’t reach: b→|3 (the digit 3 inside vertical bars), c→( (the open paren, since C looks like a left bracket), k→|< (a K made of vertical bar and angle bracket), m→// (a small m rendered as a zig-zag), n→|| (vertical bar + backslash + vertical bar), w→//, z→2. With Full, the phrase “welcome” becomes w3!c0//3 — every letter replaced, no Latin glyph remaining.

Three concrete use cases that are not novelty
The first genuinely useful case is memorable password construction. A randomly generated password like Q9!dK2#z is technically stronger than a leet-substituted English word, but a human can’t remember it; H4ck3rTh3Pl4n3t! is half as random but sticks because the underlying English word is intact under the substitutions. The converter lets you pick a memorable base phrase, apply the basic or full table, and walk away with a string that satisfies password complexity requirements while staying mnemonically grounded.

The second is OCR-ing leet text back to plain English. Old forum posts, IRC logs, MMORPG chat, even some graffiti samples use leet liberally. Reading them by eye requires keeping the substitution table in your head. The decoder mode runs the inverse pass and returns the underlying English phrase. The decoder is tolerant: it inverts every substitution it knows and passes unknown characters through unchanged, so partially-leeted or mixed text decodes sensibly even when the input uses an unusual convention.
The third is deciding when the convention is actually safer. Leet was historically used as a casual filter to evade plaintext-search keyword scans on early-2000s forums (“share warez” became “sh4r3 w4r3z”). Modern keyword scanners normalize leet, so the obfuscation property is gone. If your threat model assumes plaintext is the only thing the scanner sees, leet-encoding a password before storing it adds a thin layer of indirection — but if the threat model assumes the scanner normalizes the same way the decoder does, the layer collapses. Always sanity-check the assumption before relying on leet as a security control.
How the substitution table is built
The basic table is six rules: a→4, e→3, i→1, l→!, o→0, s→5, t→7. The full table extends those six with: b→|3, c→(, g→6, k→|<, m→//, n→||, p→|>, w→//, z→2. The caps table keeps all the same mappings and just applies them regardless of input case. Each entry is a strict equality check: when the encoder meets a in the input and Basic mode is on, it emits 4; when the decoder meets 4 in the input, it emits a. There’s no fuzzy matching, no context, no Levenshtein distance, no language model — just a dictionary lookup per character.

This strict-equality design has one important consequence: encoding is fully reversible for any text that only uses mapped characters. Encode hacker with Basic and you get h4ck3r. Decode h4ck3r with the same mode and you get hacker exactly, byte for byte. The round-trip holds because every character in hacker maps to exactly one glyph in h4ck3r, and h4ck3r contains no glyphs that map back to anything other than the original. Round-trip equality is a useful smoke test for any encoder/decoder pair: if it doesn’t round-trip, the substitution table isn’t bijective, and you’ve found a bug.
How the decoder handles third-party leet
Different leet communities picked different conventions over the years. Some used l→1 (the digit 1), some used l→! (the exclamation point), some used both interchangeably. The decoder in the Leet Speak Converter understands both — it tries ! first as the canonical reverse of l→!, then falls back to 1 as the common third-party convention. The same fallback exists for several other ambiguous glyphs. The fallback is lossy: !1 could decode to li or to ll depending on which convention you assume. The decoder picks the canonical interpretation and moves on, leaving ambiguous cases for human judgment. That’s a reasonable trade for a tool designed to make sense of partial-leet input, but it’s worth knowing the convention boundary exists before you trust the output for anything load-bearing.
Where this fits in a text-processing workflow
Leet sits inside a broader family of one-pass character transformations: rot-13, base64, URL-encoding, hex-encoding, even case-flipping. All of them are deterministic, all of them are reversible, all of them operate on a fixed alphabet, none of them need a server. The Leet Speak Converter belongs in this family — it’s a character-by-character substitution cipher dressed up as internet slang. Treat it the same way you treat rot-13: useful for obfuscation in casual contexts, useful for memorability in password construction, useful as a teaching example of how a tiny substitution table can produce something that looks like a different language.
Smoke-testing the round-trip with a pangram
If you want to extend the tool, the natural next step is a tiny test: take The quick brown fox jumps over the lazy dog (the canonical pangram — every letter of the alphabet appears at least once), run it through the basic encoder, and confirm the output contains exactly one instance of each of the seven mapped glyphs (4, 3, 1, !, 0, 5, 7). That single round-trip is enough to verify the substitution table is wired correctly. If you see i surviving in the output, the encoder skipped a character it shouldn’t have; if you see 4 surviving in a decode, the decoder missed a glyph. Both are bugs, and both are easy to spot with a one-line test. You can do the same round-trip against the Full table to verify every advanced substitution fires exactly once per mapped character across a representative input.
Try the conversion yourself
Open the Leet Speak Converter, paste any string in the text area, pick Basic / Full / Caps, and watch the output update in real time. Switch to Decode mode and paste a leet string from an old forum post to recover the underlying English. The whole thing runs in the browser — nothing is uploaded, nothing is logged, the substitution table is just a JavaScript object literal sitting next to the input handler. For more text-transformation tools in the same family (rot-13, base64, hex, URL-encode, case-flip), browse the full text-processing catalog at elysiatools.com.