DEV Community: xiao lu

Building a Unicode Text Transformer with Pure Character Maps

xiao lu — Wed, 26 Aug 2026 03:22:52 +0000

I built Unicode Text Tools, a free site with a bunch of text converters — superscript, subscript, bubble/circled text, upside-down text, small caps, and more. Type something, get it transformed, copy it out.

The whole engine is one dependency-free JS file built entirely from character mapping tables. No AI, no server, no libraries. Here's why that's the right architecture for this class of tool, and how the trickier conversions work.

The core idea: it's all just lookup tables

Every conversion on the site is a function that maps each input character to a Unicode character (or does a small transform). The simplest cases are pure dictionaries:

// Superscript (full a-z, 0-9)
var SUP = {
  a: 'ᵃ', b: 'ᵇ', c: 'ᶜ', d: 'ᵈ', e: 'ᵉ', f: 'ᶠ', g: 'ᵍ', h: 'ʰ', i: 'ⁱ',
  j: 'ʲ', k: 'ᵏ', l: 'ˡ', m: 'ᵐ', n: 'ⁿ', o: 'ᵒ', p: 'ᵖ', q: 'ᵠ', r: 'ʳ',
  s: 'ˢ', t: 'ᵗ', u: 'ᵘ', v: 'ᵛ', w: 'ʷ', x: 'ˣ', y: 'ʸ', z: 'ᶻ',
  '0': '⁰', '1': '¹', '2': '²', '3': '³', '4': '⁴', '5': '⁵',
  '6': '⁶', '7': '⁷', '8': '⁸', '9': '⁹', '+': '⁺', '-': '⁻', '=': '⁼',
  '(': '⁽', ')': '⁾'
};

The transform itself is trivial — walk the string, look up each char, append the mapped value (or the original char if unmapped). The work is in the tables: knowing which Unicode blocks exist, what's 1:1 reversible, and what's incomplete.

The Unicode reality check

Here's the thing nobody tells you about Unicode text transformation: the blocks are inconsistent.

Superscript: complete for a-z and 0-9 — fully reversible.
Subscript: incomplete — there's no subscript b, c, d, f, g, q, w, y, z. If you map an input with those letters, you have to decide what to do with them.
Small caps: x has no small-cap form (ꞯ is the closest, but it's a different character and looks wrong). j is a problem too — the Unicode small-cap ᴊ collides visually with the small-cap i in many fonts.

The site's approach: fallback keeps the original character. Unmappable input passes through unchanged rather than being silently corrupted:

function convert(text, table) {
  return text.split('').map(ch => table[ch] || ch).join('');
}

This is the pragmatic contract — "I'll transform everything I can, and leave the rest alone" — and it's honest about Unicode's limits. A subscript c just stays c, and the user understands.

Uppercase reuse: a tiny DRY trick

The superscript and subscript blocks only define lowercase. But users type "HELLO" in all caps all the time. Instead of duplicating every entry, uppercase letters are folded onto their lowercase mapping at load time:

(function addUpper(tbl) {
  Object.keys(tbl).forEach(function (k) {
    if (k >= 'a' && k <= 'z') tbl[k.toUpperCase()] = tbl[k];
  });
})(SUP);

One line, and the whole uppercase alphabet is covered without writing 26 more table entries.

The one that's not a lookup: upside-down text

Upside-down text is the interesting one, because it's not a pure per-character map. Flipping text 180° means you have to reverse the string order too — the first character visually ends up at the bottom-right.

var FLIP = {
  a: 'ɐ', b: 'q', c: 'ɔ', d: 'p', e: 'ǝ', f: 'ɟ', g: 'ƃ', h: 'ɥ', i: 'ı',
  j: 'ɾ', k: 'ʞ', l: 'l', m: 'ɯ', n: 'u', o: 'o', p: 'd', q: 'b', r: 'ɹ',
  s: 's', t: 'ʇ', u: 'n', v: 'ʌ', w: 'ʍ', x: 'x', y: 'ʎ', z: 'z',
  A: '∀', B: 'ᗺ', C: 'Ɔ', D: 'ᗡ', E: 'Ǝ', F: 'Ⅎ', G: '⅁', H: 'H', I: 'I',
  J: 'ſ', K: 'ʞ', L: '⅂', M: 'W', N: 'N', O: 'O', P: 'Ԁ', Q: 'Ό', R: 'ᴚ',
  S: 'S', T: '⊥', U: '∩', V: 'Λ', W: 'M', X: 'X', Y: '⅄', Z: 'Z',
  '?': '¿', '!': '¡', '(': ')', ')': '(', '[': ']', ']': '[', '&': '⅋', '_': '‾'
};

Notice the map is symmetric — b flips to q, and q flips back to b. Making the map symmetric means the transform is a true involution: flip the text twice and you get the original back. That's a great property for a tool — users can copy flipped text and un-flip it to verify.

The symmetry is enforced programmatically, so the table can't drift:

// Make the flip map symmetric so upside-down text reverses exactly.
Object.keys(FLIP).forEach(function (k) {
  var v = FLIP[k];
  if (v !== k && !Object.prototype.hasOwnProperty.call(FLIP, v)) FLIP[v] = k;
});

And the transformation itself reverses the string:

function flipText(s) {
  return s.split('').reverse().map(function (ch) {
    return FLIP[ch] || ch;
  }).join('');
}

Bubble text: computed, not tabulated

Bubble/circled text is the one case where a range-based calculation beats a hand-written table. The Unicode circled letters are in contiguous blocks, so they're computed on the fly:

function bubbleChar(ch) {
  var code = ch.charCodeAt(0);
  if (code >= 97 && code <= 122) return String.fromCharCode(0x24D0 + (code - 97)); // ⓐ-ⓩ
  if (code >= 65 && code <= 90) return String.fromCharCode(0x24B6 + (code - 65));  // Ⓐ-Ⓩ
  if (code >= 48 && code <= 57) {
    if (ch === '0') return '⓪';
    return String.fromCharCode(0x2460 + (code - 49)); // ①-⑨
  }
  return ch;
}

One quirk worth noting: circled 0 is ⓪, not Ⓞ — the circled digits block starts at ①, and zero lives in a different Unicode block. If you'd written a generic 0x24EA + (code - 48) you'd have produced a circled letter O instead of a circled digit. These are the details that separate a polished tool from a broken one.

Architecture takeaways

Character maps are the right tool for deterministic text transforms. They're fast, predictable, and debuggable — you can read the entire behavior of the engine by reading one table.
Fallback = keep the original. When Unicode doesn't have a mapping (subscript c, small-cap x), pass the character through rather than corrupting it.
A transform that's reversible is a feature. Symmetric flip maps let users un-flip text to verify — and the enforced symmetry prevents table drift.
Know your Unicode blocks. Circled-zero lives in a different block than circled-1-9. Contiguous ranges are computable, but verify the edge cases.

The live site is at unicodetexttools.com — superscript, subscript, bubble, small caps, upside down, and a dozen more, all in one dependency-free JS file.

Have you built a text-transform tool? What did Unicode surprise you with? Let me know in the comments.

Real-Time Pitch Detection in the Browser with YIN and the Web Audio API

xiao lu — Tue, 25 Aug 2026 03:59:27 +0000

I built PitchTester, a free online pitch detector. You open the page, allow microphone access, and sing or play an instrument — it shows the note name, frequency in Hz, and how sharp or flat you are in cents, all in real time.

The entire thing is one vanilla JavaScript file. No backend, no WebAssembly, no dependencies. Here's how the audio math works, and how I kept it accurate enough to actually be useful.

The pipeline

Getting from microphone to a note name is four steps:

Capture — getUserMedia → AudioContext → AnalyserNode
Detect pitch — YIN autocorrelation on the time-domain buffer
Map to a note — twelve-tone frequency → note name + cents
Constrain by voice range — filter octave mis-reads

Step 1: Capture

The Web Audio API makes the plumbing nearly free:

function getAudioCtx() {
  if (!audioCtx) audioCtx = new (window.AudioContext || window.webkitAudioContext)();
  if (audioCtx.state === 'suspended') audioCtx.resume();
  return audioCtx;
}

An AnalyserNode gives us the raw time-domain samples we need for autocorrelation. No FFT required for pitch detection — that's a common misconception. The YIN algorithm works directly on the time-domain buffer.

Step 2: YIN pitch detection

YIN (the "You In" pitch detection algorithm, de Cheveigné & Kawahara 2002) is the workhorse here. The core idea: find the smallest period at which the signal correlates with itself. That period is the fundamental frequency's wavelength.

First, compute the difference function — for each candidate period τ, sum the squared difference between the signal and itself shifted by τ:

const diff = new Float32Array(tauMax + 1);
for (let tau = 1; tau <= tauMax; tau++) {
  let sum = 0;
  for (let i = 0; i < buffer.length - tau; i++) {
    const d = buffer[i] - buffer[i + tau];
    sum += d * d;
  }
  diff[tau] = sum;
}

At the true period, the signal aligns with itself, so the difference is at a minimum. But raw difference values aren't comparable across pitches, so YIN normalizes with the cumulative mean normalized difference (CMND):

const cmnd = new Float32Array(tauMax + 1);
cmnd[0] = 1;
let running = 0;
for (let tau = 1; tau <= tauMax; tau++) {
  running += diff[tau];
  cmnd[tau] = running === 0 ? 1 : (diff[tau] * tau) / running;
}

Then find the first τ where the CMND drops below a threshold (0.15 in my implementation). That's the estimated period:

let tauEst = -1;
for (let tau = tauMin; tau <= tauMax; tau++) {
  if (cmnd[tau] < threshold) {
    while (tau + 1 <= tauMax && cmnd[tau + 1] < cmnd[tau]) tau++;
    tauEst = tau;
    break;
  }
}
// Fallback: global min
if (tauEst === -1) {
  let minV = Infinity;
  for (let tau = tauMin; tau <= tauMax; tau++) {
    if (cmnd[tau] < minV) { minV = cmnd[tau]; tauEst = tau; }
  }
}

Finally, parabolic interpolation around the minimum gives sub-sample accuracy — this is what takes the frequency estimate from "close" to "in tune":

if (tauEst > 0 && tauEst < tauMax) {
  const s0 = cmnd[tauEst - 1], s1 = cmnd[tauEst], s2 = cmnd[tauEst + 1];
  const denom = s0 - 2 * s1 + s2;
  if (denom !== 0) {
    const shift = (s0 - s2) / (2 * denom);
    bestTau = tauEst + Math.max(-1, Math.min(1, shift));
  }
}
const freq = sampleRate / bestTau;

Step 3: Frequency → note name + cents

Twelve-tone mapping is straightforward math. Semitones from A4, rounded to the nearest note, and cents as the residual:

function freqToNote(f, a4) {
  const semis = 12 * Math.log2(f / a4);
  const rounded = Math.round(semis);
  const nearestFreq = a4 * Math.pow(2, rounded / 12);
  let cents = Math.round(1200 * Math.log2(f / nearestFreq));
  if (cents > 50) cents -= 100;
  if (cents < -50) cents += 100;
  const idx = ((rounded + 9) % 12 + 12) % 12; // A is 9 semitones above C
  const octave = Math.floor((rounded + 9) / 12) + 4; // A4 -> octave 4
  return { name: NOTE_NAMES[idx] + octave, cents: cents };
}

Step 4: The voice-range constraint (the trick that matters)

Raw YIN is accurate for monophonic audio, but it has a classic failure mode: octave errors. Sing a low A and it might report A5 — the algorithm latched onto a harmonic instead of the fundamental.

The fix is domain-specific and cheap: let the user pick their voice range, and clamp detection to that octave band:

const VOICE_RANGES = {
  soprano:  [175, 880],   // F3–A5
  mezzo:    [147, 784],   // D3–G5
  alto:     [123, 659],   // B2–E5
  tenor:    [110, 494],   // A2–B4
  baritone: [82, 392],    // E2–G4
  bass:     [65, 330]     // C2–E4
};

The YIN search range (tauMin/tauMax) is derived from these bounds, so the detector simply can't lock onto a harmonic outside the singer's range. This one feature eliminated the most common "wrong note" complaint.

Bonus: key detection with Krumhansl-Schmuckler

While I was at it, the same engine powers a song key finder. It builds a pitch-class histogram from detected notes, then correlates it against the Krumhansl-Schmuckler major and minor key profiles:

const KS_MAJOR = [6.35, 2.23, 3.48, 2.33, 4.38, 4.09, 2.52, 5.19, 2.39, 3.66, 2.29, 2.88];
const KS_MINOR = [6.33, 2.68, 3.52, 5.38, 2.60, 3.53, 2.54, 4.75, 3.98, 2.69, 3.34, 3.17];

For each of the 12 roots × 2 modes, rotate the profile and compute Pearson correlation against the observed histogram. The best match wins:

function detectKey(histogram) {
  const results = [];
  for (let root = 0; root < 12; root++) {
    const major = KS_MAJOR.map((_, i) => KS_MAJOR[(i - root + 12) % 12]);
    const minor = KS_MINOR.map((_, i) => KS_MINOR[(i - root + 12) % 12]);
    results.push({ key: KEY_NAMES[root], type: 'major', corr: pearson(histogram, major) });
    results.push({ key: KEY_NAMES[root], type: 'minor', corr: pearson(histogram, minor) });
  }
  results.sort((a, b) => b.corr - a.corr);
  const best = results[0], alt = results[1];
  return {
    key: best.key + (best.type === 'minor' ? 'm' : ''),
    alt: alt.key + (alt.type === 'minor' ? 'm' : ''),
    confidence: Math.max(0, best.corr - alt.corr)
  };
}

The confidence (gap between best and second-best correlation) tells the user how sure the detector is — a common real-world pitfall is that a song with mostly C and G notes is ambiguous between C major and G major.

Key takeaways

YIN beats FFT for monophonic pitch detection. It's simpler to implement correctly, more accurate at the edges, and needs no windowing tricks.
Domain constraints beat generic algorithms. The voice-range filter is the difference between a demo and a usable tool.
Sub-sample interpolation is what makes it "in tune". Without parabolic interpolation, the cents reading jumps ±10 cents randomly.
Everything runs in the browser, privately. No audio ever leaves the device — which is both a privacy win and an infrastructure win (zero servers, zero cost).

The live tool is at pitchtester.com — try singing into it and see how close you are to perfect pitch. The full engine is a single dependency-free JS file.

Have you built anything with the Web Audio API? I'd love to hear how you handled pitch accuracy in the comments.

Building a 100% Client-Side Word Puzzle Solver with a Trie and DFS

xiao lu — Mon, 24 Aug 2026 08:07:49 +0000

A few weeks ago I built StrandsSolver, a free solver for the NYT Strands daily word puzzle. The whole thing runs in the browser — no backend, no database, no API calls. You paste a letter grid, and it finds every valid word instantly.

There were two constraints that made this interesting:

It has to be fast. A 6×6 grid with 8-direction movement has a huge search space. If the solver takes more than a second, people close the tab.
It has to be private. The grid you paste should never leave your device. That means the entire word list — 171,755 words — lives in a single JavaScript file, and all the work happens client-side.

Here's how it works under the hood.

The core algorithm: Trie + DFS with prefix pruning

The solver is conceptually simple: for every cell in the grid, do a depth-first search in all 8 directions, and at each step check whether the current path is still a valid prefix of some word. If it's not, prune the branch immediately.

The key data structure that makes this fast is a Trie (prefix tree). Instead of scanning the whole dictionary for each prefix, we walk the Trie one letter at a time. If a node has no child for the next letter, that branch is dead — we stop recursing.

function TrieNode() {
  this.children = Object.create(null);
  this.isEnd = false;
}

function buildTrie(words) {
  const root = new TrieNode();
  for (let i = 0; i < words.length; i++) {
    const w = words[i];
    let node = root;
    for (let j = 0; j < w.length; j++) {
      const c = w[j];
      if (!node.children[c]) node.children[c] = new TrieNode();
      node = node.children[c];
    }
    node.isEnd = true;
  }
  return root;
}

With Object.create(null) as the child map, lookup is a plain property access — no prototype chain, no hash collisions, just a direct jump. For 171k words of average length ~8, building the Trie takes about 100ms, and we only do it once per solve.

The DFS

The grid is flattened into a single array, and the DFS walks 8 direction deltas:

const DIRS = [
  [-1,-1], [-1,0], [-1,1],
  [0,-1],          [0,1],
  [1,-1],  [1,0],  [1,1],
];

function dfs(pos, node, depth) {
  const ch = flat[pos];
  const child = node.children[ch];
  if (!child) return;  // prefix not in dictionary — prune

  path[depth] = pos;
  onPath[pos] = 1;

  if (child.isEnd && depth >= 3) {
    // depth is 0-indexed → depth+1 letters; Strands min is 4
    const word = snapshotWord(depth);
    if (!found.has(word)) found.set(word, snapshotPath(depth));
  }

  const r = (pos / cols) | 0;
  const c = pos % cols;
  for (let d = 0; d < 8; d++) {
    const nr = r + DIRS[d][0], nc = c + DIRS[d][1];
    if (nr < 0 || nc < 0 || nr >= rows || nc >= cols) continue;
    const np = nr * cols + nc;
    if (onPath[np]) continue;  // no cell repeats within a word
    dfs(np, child, depth + 1);
  }

  onPath[pos] = 0;  // backtrack
}

for (let start = 0; start < total; start++) {
  dfs(start, trie, 0);
}

A few details worth calling out:

onPath as a Uint8Array: marking visited cells and clearing them on backtrack is O(1), and typed arrays are fast to allocate and read.
No cell may repeat within a word — that's a Strands rule, enforced by the onPath check.
Prefix pruning is the whole game. Without the Trie, a branch that starts with QZ would keep recursing pointlessly. With it, QZ dies at depth 2, and the entire subtree below is never visited.

Parsing forgiving input

The other 50% of "it just works" is input parsing. Players paste grids in wildly different formats — newlines, commas, spaces, no separators at all, lowercase, with stray characters.

// Split rows by newline; if it's a one-liner, try comma/semicolon split
let rowLines = cleaned.split('\n').map(s => s.trim()).filter(Boolean);
if (rowLines.length === 1 && /[,;]/.test(rowLines[0])) {
  rowLines = rowLines[0].split(/[,;]/).map(s => s.trim()).filter(Boolean);
}

Each cell is uppercased and stripped of non-letters. Rows are validated to be rectangular, with a hard cap of 100 cells so a pathological paste can't freeze the tab:

if (grid.length * cols > 100) {
  throw new Error('Grid is too large (max 100 cells).');
}

The spangram heuristic

Strands has a special word type called the spangram — a theme word that spans from one edge of the board to the opposite edge. Since we don't know the official theme, we can't know for sure which word is the spangram, but we can flag strong candidates: any found word whose path touches two opposite edges.

if ((touchesTop && touchesBottom) || (touchesLeft && touchesRight)) {
  spangramCandidates.push(w);
}

It's a heuristic, not a guarantee — but in practice it surfaces the right word most days, which is all the user needs.

Performance

On a 6×6 grid with the full 172k-word dictionary, the solver finds every valid word in well under 100ms on a mid-range laptop, and a couple hundred ms on a phone. The Trie keeps the search space tiny: most branches die within 2–3 letters.

That speed is the whole product. A solver that takes 3 seconds to respond feels broken; one that answers instantly feels like magic.

Why client-side?

Beyond privacy, going 100% static means zero infrastructure cost and zero maintenance:

No server to scale, no API key to rotate, no database to back up
Deploys anywhere — Cloudflare Pages, Netlify, GitHub Pages, a USB stick
The word list is public domain (ENABLE), so there's no licensing concern

The tradeoff is a heavier first page load (the 172k-word JS file is ~1.5MB raw, ~250KB gzipped), which we mitigate with a small loading state and by keeping the solver logic in a separate file so it parses only when needed.

Key takeaways

If you're building anything that searches a big word space in the browser:

A Trie + DFS with prefix pruning is hard to beat for "find all valid words on a grid" problems. It's simple, fast, and memory-light.
Typed arrays and flat arrays beat nested structures for hot paths. Flattening the grid and using Uint8Array for visited-state makes a measurable difference.
Prune early, prune often. Every wasted recursion level multiplies through the tree. The Trie is the pruning.
Forgiving input parsing is a feature. Users paste grids from screenshots, tweets, and other apps — the parser doing the cleanup is what makes the tool feel instant and effortless.

The full source is on GitHub at strandssolver, and you can try the live solver at strandssolver.org.

If you've built something similar — Boggle solvers, Scrabble helpers, crossword tools — I'd love to hear how you handled the dictionary. Drop a comment below.

Generating 50+ SEO Landing Pages from a Static Site Build Script

xiao lu — Mon, 24 Aug 2026 03:21:19 +0000

I run TextTimeTools, a free site with speaking-time and reading-time calculators. It's a pure static site deployed to Cloudflare Pages — no backend, no database, no CMS.

The calculators themselves are one page. But the site has 50+ pages, each targeting a different keyword like "how many words is a 5 minute speech" or "how long to read 1000 words". Every single one of those pages is generated by a build script. I've never written one by hand.

Here's the pattern, and why it's the highest-leverage thing I've done for this site's organic traffic.

The problem with a single calculator page

A speaking-time calculator answers one query well: "how many words is my speech". But people don't search for tools — they search for answers:

"how many words is a 5 minute speech"
"how many words for a 3 minute speech"
"how long to read 1000 words"
"how long to read 5000 words"

Each of those is a separate keyword with its own search intent and its own competition. One calculator page can't rank for all of them — a page titled "Speaking Time Calculator" has no reason to show up for "how long to read 1000 words".

The classic fix is to write a page per keyword. That works, but it doesn't scale — every new keyword means hand-writing another page, and keeping them consistent is a nightmare.

The fix: generate pages at build time

The build script (gen-longtail.cjs) takes a list of keyword targets and emits a complete, keyword-specific HTML page for each one. The word count pages and reading time pages are both generated this way.

const PAGES = [
  { minutes: 1,  slug: 'how-many-words-is-a-1-minute-speech',  variant: 'is-a' },
  { minutes: 2,  slug: 'how-many-words-is-a-2-minute-speech',  variant: 'is-a' },
  { minutes: 5,  slug: 'how-many-words-is-a-5-minute-speech',  variant: 'is-a' },
  // ... up to 15 minutes
  { minutes: 2,  slug: 'how-many-words-for-a-2-minute-speech',  variant: 'for-a' },
  { minutes: 5,  slug: 'how-many-words-for-a-5-minute-speech',  variant: 'for-a' },
];

For each entry, the script computes the answer from a speed table, then renders a full HTML page with:

A keyword-exact <title> and <h1> ("How Many Words Is a 5 Minute Speech?")
The answer computed in the page content (e.g., "at 130 WPM, a 5-minute speech is about 650 words")
A speed selector table with the full calculation
FAQ section with schema markup, each Q&A pre-written for that keyword

The page body is not templated filler — the numbers are real, computed from the same logic the calculator uses, so the answer is always consistent across the site.

The build pipeline

The whole thing runs on npm run build:

{
  "scripts": {
    "gen:longtail": "node scripts/gen-longtail.cjs",
    "gen:reading": "node scripts/gen-reading.cjs",
    "build": "npm run gen:longtail && npm run gen:reading && node scripts/build-site.mjs && node scripts/gen-sitemap.mjs",
    "deploy": "npm run build && wrangler pages deploy dist --project-name texttimetools --branch main"
  }
}

Four steps, in order:

gen-longtail.cjs — generates the "how many words is a X minute speech" pages
gen-reading.cjs — generates the "how long to read N words" pages
build-site.mjs — assembles dist/, copying only the public files plus any auto-discovered generated page directories
gen-sitemap.mjs — reads the actual dist/ contents and writes sitemap.xml

The sitemap step is the sneaky-important one. Instead of maintaining a URL list by hand, it discovers the pages that actually exist after the build:

const prefixes = ['how-many-words-', 'how-long-to-read-'];
for (const entry of readdirSync(DIST)) {
  if (!prefixes.some(p => entry.startsWith(p))) continue;
  if (!existsSync(join(DIST, entry, 'index.html'))) continue;
  urls.push({ loc: `${SITE}/${entry}/`, priority: '0.7', freq: 'monthly' });
}

If a generator stops producing a page, it automatically drops out of the sitemap. No orphaned URLs, no manual sync.

Why this works

1. Each page is actually good

Generated doesn't mean thin. Every page has a real computed answer, a real FAQ, and schema markup. They're as useful as a hand-written page — because the template was hand-written once, with care, and the data is real.

2. Adding a keyword is a one-line change

Want to target "how many words is a 12 minute speech"? Add one object to the array, rebuild, deploy. The page, sitemap entry, and internal links all update automatically.

3. Consistency is guaranteed

Every page uses the same WPM table and the same calculation. A reader who lands on the 5-minute page and the 10-minute page gets answers that agree — which builds trust and reduces bounce.

4. The sitemap can't lie

Because it's generated from what's actually in dist/, the sitemap always matches reality. This is the kind of thing that quietly breaks on hand-maintained sites (page deleted, sitemap stale) and wastes crawl budget.

Practical notes

Keyword research comes first. Each entry in the PAGES array is a keyword with measured search volume. The generator is a factory, but the what still comes from research.
Numbers should match the tool. The page answers and the calculator use the same formulas, so a visitor can verify the answer interactively. That combination — instant answer + interactive tool — is what makes a landing page convert.
Keep the template in one place. When I update the WPM table or the FAQ copy, every generated page picks it up on the next build. That's the whole point.

The results

This pattern took the site from one page to 50+ keyword-targeted pages with maybe two hours of script-writing and zero ongoing manual work. It's the difference between "I have a calculator" and "I rank for the questions people actually ask."

The live site is at texttimetools.com — all pages generated, all static, all free.

If you have a tool that answers a family of questions, this pattern is worth stealing. Have you generated SEO pages from build scripts? I'd love to hear what worked and what didn't in the comments.

I Built an AI Tool That Turns PDFs into Editable Anki Flashcards

xiao lu — Wed, 12 Aug 2026 09:05:07 +0000

Turning a PDF into flashcards sounds simple until you actually try to make cards that are useful for review.

The hard part is not generating text. AI can do that quickly.

The hard part is getting cards that are short, accurate, editable, and not full of vague questions you would never want to review later.

That is the problem I had in mind when building CardForge AI: a tool for turning PDFs and study notes into editable Anki flashcards.

This is not a launch announcement. It is more of a build note about why I chose this workflow, what I think the real problem is, and why I do not believe AI-generated flashcards should go straight into a study system without review.

The Problem Is Not Just “PDF to Flashcards”

A lot of learning material starts as a long document.

It might be a textbook chapter, a lecture handout, a research paper, a course PDF, or a set of messy notes. When you want to study from it later, Anki is a good tool because spaced repetition actually forces you to review over time.

But creating Anki cards manually is slow.

You need to read the material, find the important points, rewrite them into questions, make the answers short enough, avoid duplicates, and keep the cards clear. If the source material is long, this can take longer than the actual first reading.

At first glance, AI seems like the obvious fix.

Just upload a PDF, ask the model to generate flashcards, export everything, and start reviewing.

But when I looked at the workflow more carefully, I kept seeing the same issue: generated cards are often only a first draft.

Some cards are too broad. Some include too much information in the answer. Some ask questions that are technically correct but not useful. Some miss the point of the original paragraph. Some cards are just not worth reviewing.

That is why I started thinking less about “automatic flashcard generation” and more about “helping someone create a better first draft of a deck.”

Why Editable Cards Matter

One design choice I made early was that the generated cards should be editable before export.

This sounds like a small thing, but I think it changes the whole product.

If the tool only gives you a one-click export, the user has to trust the AI output immediately. That may be fine for rough notes, but it is risky for serious study. Once poor cards enter Anki, they become part of your review queue. You might spend weeks reviewing cards that were badly written from the start.

For learning, card quality matters.

A useful flashcard should usually test one idea. The question should be clear. The answer should be short enough to recall. The card should not depend on a huge paragraph of context. And if the source material is technical, the wording needs to be checked.

AI can help with the first draft, but the learner still needs control.

That is why I wanted the flow to be:

Upload the learning material.
Generate draft flashcards.
Review and edit the cards.
Export them into the study workflow.

The AI reduces the boring first pass, but the human still decides what is worth keeping.

The Workflow I Wanted

The basic workflow is intentionally simple.

You start with a PDF or notes. The tool extracts the content and generates flashcards from it. Instead of treating the output as finished, the cards are shown in an editable format.

From there, the user can scan the questions, adjust wording, remove weak cards, and fix answers before exporting.

This is the part I care about most.

I do not want the product to pretend that AI can magically understand every learner’s goal. A medical student, a language learner, and a software developer may all use flashcards differently. The same source document can produce different “good cards” depending on what the person is trying to remember.

So the product should not remove the learner from the process.

It should save time on the mechanical part, then make the review step easier.

What I Learned While Building It

The first lesson is that AI output needs a product shape around it.

If you simply return a long AI response, the user still has work to do. They have to copy, split, clean, format, and import. That is not really a workflow. It is just an answer.

For this kind of tool, the interface matters because the user is not only reading the AI output. They are deciding what to keep.

The second lesson is that “more cards” is not always better.

A long PDF can produce a lot of possible questions, but a large deck is not automatically useful. Too many weak cards can make review painful. I would rather help users create fewer, clearer cards than generate a huge deck that feels impressive but becomes a burden later.

The third lesson is that export is not the whole product.

It is tempting to focus on the final file: “Can this become an Anki deck?” But the more important part is what happens before export. If the cards are poor, a perfect export format does not solve the learning problem.

The fourth lesson is that AI study tools need honesty.

There is a big difference between “AI can help you create study material faster” and “AI can replace your judgment.” I am much more comfortable building around the first idea.

What I Am Still Not Sure About

There are still open questions.

For example, should the tool generate fewer cards by default and prioritize quality? Or should it generate more cards so the user can delete the weak ones?

Should the product focus on direct Q&A cards first, or support more card types later?

Should the editing step be very lightweight, or should it include stronger review tools for merging duplicates and improving wording?

I do not think these are purely technical questions. They are product questions. The right answer depends on how people actually study.

That is why I am trying to keep the first version focused instead of adding every possible feature at once.

The Main Product Decision

If I had to summarize the product decision in one sentence, it would be this:

AI should create the first draft, but the learner should approve the deck.

That is the direction I am building toward with CardForge AI.

The goal is not to replace Anki or replace the learning process. The goal is to make the painful part faster: turning long material into a set of cards you can actually review.

I built CardForge AI around this workflow: generate a first draft, review and edit the cards, then export them into your study system.

You can try it here: https://cardforgeai.com/

I would especially like to know this: when you create flashcards, what takes more time for you — deciding what is important, writing the cards, or cleaning up the final deck?