DEV Community: Veronica Lin

Leet Speak, Explained: From 1980s BBS Culture to a Reversible 1337 Alphabet

Veronica Lin — Tue, 15 Sep 2026 10:44:38 +0000

If you have ever seen a username like xX_5p34k3r_Xx and instinctively read it as "speaker", you already know leet speak. What looks like keyboard noise is actually one of the oldest consistent writing systems on the internet — and it is far more rule-bound than most people expect.

This post walks through where leet came from, how the substitution alphabet actually works, why some leet text decodes cleanly while some does not, and how a deterministic translator differs from an AI paraphrasing tool.

A very short history

Leet (from "elite", written 1337) showed up in 1980s bulletin board systems and Usenet groups. Skilled users — the "elites" — adopted distorted spellings partly as an in-group marker and partly to evade crude keyword filters. The style survived the death of Usenet and is still everywhere: gaming handles, stylized screen names, forum memes, and winking error messages in production code.

The core idea never changed: replace each letter with a number or symbol that looks similar.

The three tiers of substitution

Not all leet is equal. In practice the alphabet comes in three rough tiers:

Light (sometimes called "lite") — only the most common substitutions:

Letter	Replaces with
a	4
e	3
o	0
s	5

Text stays very readable: leet becomes 1337 in name only when you also swap l and t, so light mode usually renders it l33t.

Classic — the standard 1337 alphabet most people recognize. Roughly fifteen letters get swapped, including t → 7 and l → 1. Under classic rules, Cat becomes C47: uppercase C has no mapping and passes through, a becomes 4, t becomes 7.

Extreme — multi-character ASCII art replacements where single letters balloon into symbols: m becomes |\/|, n becomes |\|, w becomes \/\/. Maximum stylization, minimum readability, and — as we will see — the hardest tier to decode automatically.

Encoding is easy; decoding is the interesting problem

A deterministic encoder is trivial: walk the string, look up each letter in a fixed mapping table, emit the replacement. Because every input letter maps to at most one output token and the encoder never re-processes its own output, encoding is stable — the same input always produces the same output. No randomness, no model.

Decoding is where it gets interesting, for two reasons:

The mapping is not injective. In classic mode both i and l map to 1, and both e and a can end up represented by characters that collide in the other direction. Given 1, a decoder cannot know which letter was intended. There is no information to recover — it was destroyed at encode time.
Tokens have variable length. In extreme mode |\/| is a single letter (m), not three symbols. A naive one-character-at-a-time decoder would mangle it. The standard fix is longest-match-first scanning: at each position, try to match the longest token in the reverse mapping before falling back to single characters. With that rule, |\/| correctly resolves to m instead of three garbage characters.

So the honest mental model is: encoding is a function, decoding is a probabilistic best effort. A good decoder returns the most likely reading given the mapping, and tells you — by its collisions — which parts of the original were lossy.

Why a fixed mapping beats a language model here

It is tempting to throw a small LLM at leet decoding, but that is the wrong tool:

Determinism. Fixed rules give reproducible output. If you use leet in test fixtures or demo data, you want leet → 1337 every single time, not a sample from a distribution.
Auditability. A visible mapping table can be inspected, diffed, and customized. A model's reasoning cannot.
Cost and privacy. Character substitution runs in a few microseconds on any device, requires no network round trip, and never sends your text anywhere.

For edge cases like stylized usernames where leet mixes with keyboard mashing, sure, probabilistic methods help. But for the 95% case — converting between readable text and a known substitution alphabet — a lookup table with longest-match decoding is simpler, faster, and exact where exactness is possible.

If you want to see this in action, the Leet Speak Translator implements exactly this design: three preset tiers, an inspectable character-mapping table you can edit per session, one-pass stable encoding, and longest-match decoding. It also runs entirely in the browser, which is a nice property for a tool whose input is often a draft username you do not want to send to a server.

Rolling your own in fifteen lines

The encoding half is a nice beginner exercise in exactly one concept: lookup tables.

const CLASSIC = { a: '4', e: '3', i: '1', l: '1', o: '0', s: '5', t: '7' /* ... */ };

function encode(text, mapping) {
  // Uppercase letters without a mapping pass through unchanged.
  return [...text]
    .map((ch) => mapping[ch.toLowerCase()] ?? ch)
    .join('');
}

Decoding needs the longest-match rule:

function decode(text, mapping) {
  // Build reverse index: token -> most likely source letter.
  const reverse = {};
  for (const [letter, token] of Object.entries(mapping)) {
    if (!(token in reverse)) reverse[token] = letter;
  }
  const tokens = Object.keys(reverse).sort((a, b) => b.length - a.length);
  let out = '';
  let i = 0;
  while (i < text.length) {
    const hit = tokens.find((t) => text.startsWith(t, i));
    if (hit) { out += reverse[hit]; i += hit.length; }
    else { out += text[i]; i += 1; }
  }
  return out;
}

That is the whole trick. No neural nets were harmed.

Takeaways

Leet speak is a fixed substitution system, not random decoration — it has tiers, rules, and a documented alphabet.
Encoding is stable and trivial; decoding is lossy where the mapping collides and needs longest-match scanning for multi-character tokens.
Deterministic lookup beats probabilistic models when you need reproducibility, auditability, or privacy.
And if a recruiter ever asks you to "decode 1337" in a take-home, you now know it is a parsing problem, not a machine-learning problem.

Normal Maps Explained for Game Devs: Turn a Flat Texture into Surface Detail

Veronica Lin — Tue, 15 Sep 2026 07:09:30 +0000

If you've ever slapped a high-res texture on a low-poly model and felt something was missing, the missing piece is usually surface detail — the bumps, grooves and ridges that catch light differently as the camera moves. That's exactly what normal maps fake, and you don't need a DCC license to make one.

What a normal map actually stores

A normal map is an RGB image where each pixel encodes a surface direction instead of a color:

R = X axis (left/right tilt)
G = Y axis (up/down tilt)
B = Z axis (facing out of the surface)

Your shader reads these directions and perturbs the lighting normal per-pixel, so a flat quad can shade as if it had real geometry. The silhouette stays flat — normal maps don't change the outline — but the lighting response is convincingly 3D.

Two conventions exist for the green channel:

OpenGL: Y+ points up (the Blender/Maya/WebGL convention)
DirectX: Y+ points down (the Unreal/Unity default)

Feeding one convention to an engine expecting the other is the classic "my normal map looks inverted" bug. It's a one-line fix — flip the green channel — but you need to know which one you have.

Where normal maps come from

There are two common sources:

Baked from high-poly geometry (Blender, Substance, xNormal). Best quality, heaviest workflow.
Converted from a grayscale height/bump image. The converter estimates slopes from brightness differences and turns them into normals. That's 90% of what you need for props, walls, ground and anything tiling.

For source #2, the pipeline used to be: open GIMP, install a normal-map plugin, fiddle, export. For quick iterations that's friction you don't need.

A browser-based alternative

I've been maintaining a small free tool for the second workflow — Normal Map Generator. It runs entirely in the browser:

Drop in any image (height map, grayscale photo, even a diffuse texture)
Live sliders for strength, smoothing, edge handling and a lighting preview so you see the result on a 3D-ish surface before exporting
Choose OpenGL or DirectX output up front instead of discovering the convention mismatch later
Nothing is uploaded — processing happens locally, which matters when your texture is unreleased game art

Typical use case: you generated a seamless stone texture, you need a matching normal map now, and you're 40 minutes from a build deadline. Drop it in, push strength until the grooves read, export, done.

Quick sanity checks after generating one

Whatever tool you use, verify:

Preview with moving light. If the bumps look like craters, your height map is inverted (or you picked the wrong convention).
Watch the seams. On tiling textures, crank edge handling; naive conversion brightens seams at tile boundaries.
Strength is not fidelity. Overshooting strength produces that shiny "gravel" look. If everything looks wet, turn it down.
Silo check. Remember: the silhouette is unchanged. Normal maps carry lighting detail; if the outline needs to change, that's geometry or a displacement map's job.

Takeaway

Normal maps are the highest value-per-pixel trick in real-time rendering, and the height-image conversion route covers most day-to-day asset work. Bake from high-poly when you're hero-ing a character; convert from grayscale when you're shipping 200 environment props. Match the OpenGL/DirectX convention to your engine, preview before you export, and keep the strength honest.

Designing Clean Roblox GUIs: Grid, Contrast, and the 3-Click Rule

Veronica Lin — Sat, 08 Aug 2026 03:18:52 +0000

Designing Clean Roblox GUIs: Grid, Contrast, and the 3-Click Rule

A Roblox game lives or dies by its UI. Players decide in seconds whether a game "feels" polished, and most of that feeling comes from the interface — health bars, inventory, shop buttons, loading screens. Yet a lot of Roblox GUIs are cluttered, low-contrast, and hard to tap on mobile.

Here are the rules I keep coming back to.

1. Build on a grid, not by eye

Roblox Studio's UIAspectRatioConstraint + UIGridLayout let you snap elements to a grid instead of dragging them freehand. Freehand layout looks fine on your monitor and breaks on every other screen. Pick a base cell size (e.g. 80×80) and make everything a multiple of it.

A white health bar on a light background is invisible. Aim for at least 4.5:1 contrast on text and key elements. Dark UI over a dark game scene? Add a stroke — UIStroke is cheap and fixes readability instantly.

3. The 3-click rule

A player should reach any core action (equip, buy, start) in 3 taps or fewer. If your shop is 4 menus deep, players leave before they spend Robux. Flatten it: one main HUD, one overlay panel per feature.

4. Mobile-first sizing

Most Roblox players are on phones. A button that's comfortable on desktop is often too small to tap reliably on a 6" screen — minimum touch target ~48×48 px. Size with Scale, not Offset, so the UI scales with the viewport.

5. Reuse components

Don't rebuild a button 12 times. Make one button template (Frame + TextLabel + UIStroke + UICorner + LocalScript) and clone it. This is the single biggest time-saver in Roblox UI work.

The fast path

If you'd rather not hand-roll every panel, a Roblox GUI maker lets you assemble common components and drop them straight into Studio — handy for prototyping before you commit to a fully custom design.

How to Add an Authentic VHS Effect to Video in the Browser

Veronica Lin — Fri, 07 Aug 2026 14:17:51 +0000

If you've wanted that worn VHS look on a video without opening After Effects, here's what actually creates the effect and how to do it in the browser.

What makes footage look "VHS"

Four things do most of the work:

Tracking lines — horizontal distortion bands that drift vertically.
Chroma shift — the red/blue channels offset from green, visible at edges.
Grain and noise — analog signal hiss, brighter in dark areas.
Date stamp — that blocky timestamp in the corner.

Strip any of these and it stops reading as VHS. Add all four and even a clean clip looks dubbed.

Browser approaches

Canvas 2D — read each frame's pixels, shift the R and B channels a few pixels apart for chroma shift, overlay a noise pattern, and draw moving horizontal bands. Cheap and good enough for short clips.

CSS filters — for static polish, filter: contrast() saturate() hue-rotate() plus an animated noise overlay gets you 70% of the look with almost no code. No per-pixel work.

WebGL shaders — the convincing route. A fragment shader can do time-based distortion, real chroma aberration, and scanlines at 60fps. More setup, best result.

The shortcut

If you just want the result and not the implementation, run the clip through this free online VHS video filter — it applies the full effect (tracking, chroma shift, grain, date stamp) in the browser, no install, no upload to a server. Handy when you need one clip done fast.

Closing

The interesting thing about the VHS aesthetic is that it's entirely reproducible from four well-understood artifacts. Once you know which visual cue does what, you can implement it at whatever fidelity your stack allows — from a 10-line CSS version up to a full shader.