cd /news/open-source/building-a-privacy-first-resume-edit… Β· home β€Ί topics β€Ί open-source β€Ί article
[ARTICLE Β· art-10440] src=dev.to β†— pub= topic=open-source verified=true sentiment=↑ positive

Building a Privacy-First Resume Editor with Typst WASM and React

The article describes SmartResume, a privacy-first resume builder that combines React with Typst compiled to WebAssembly to provide professional typesetting entirely within the browser. The application runs as a single-page app where all data is stored locally in IndexedDB, with compilation handled in a Web Worker to prevent UI blocking. The editor features a block-based interface similar to Notion, with both rich text and raw Typst source editing modes, and uses a message protocol with incrementing IDs to handle stale compilation results.

read8 min views21 publishedMay 23, 2026

The Problem #

Most online resume builders fall into two camps:

SaaS tools that upload your resume to a server for PDF generation β€” your most sensitive personal data leaves your machine. - LaTeX/Typst templates that produce great output but require a local toolchain, package manager, and CLI fluency.

For non-technical users, option 2 is inaccessible. For privacy-conscious users, option 1 is unacceptable. SmartResume tries to solve both: professional typesetting quality, entirely in the browser.

You can try it at resume.kakuti.site. The source is on GitHub.

Architecture at a Glance #

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚                   Browser (SPA)                   β”‚
β”‚                                                   β”‚
β”‚  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”   β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”   β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚
β”‚  β”‚  React   │──▢│  Editor   │──▢│  IndexedDB   β”‚ β”‚
β”‚  β”‚  Pages   β”‚   β”‚  State    β”‚   β”‚ (localforage)β”‚ β”‚
β”‚  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜   β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜   β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β”‚
β”‚                       β”‚                           β”‚
β”‚                       β–Ό                           β”‚
β”‚              β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”                  β”‚
β”‚              β”‚   Web Worker    β”‚                  β”‚
β”‚              β”‚  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚                  β”‚
β”‚              β”‚  β”‚ Typst WASM β”‚ β”‚                  β”‚
β”‚              β”‚  β”‚ Compiler + β”‚ β”‚                  β”‚
β”‚              β”‚  β”‚ Renderer   β”‚ β”‚                  β”‚
β”‚              β”‚  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β”‚                  β”‚
β”‚              β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜                  β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                      β”‚
                β”Œβ”€β”€β”€β”€β”€β–Όβ”€β”€β”€β”€β”€β”€β”
                β”‚   Vercel   β”‚
                β”‚  /api/     β”‚  ← Discord webhook
                β”‚  feedback  β”‚     (optional)
                β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

The application is a single-page app (React 18 + Vite 5 + TypeScript). There is one serverless function for optional feedback β€” everything else runs client-side.

How Typst Runs in the Browser #

Typst is a modern typesetting language, like LaTeX but with a cleaner syntax and faster compilation. The key insight is that Typst's compiler and renderer can be compiled to WebAssembly via @myriaddreamin/typst.ts.

Two WASM binaries handle the pipeline:

Binary Purpose Size
typst_ts_web_compiler_bg.wasm
Parses .typ source, produces a document AST
~8 MB
typst_ts_renderer_bg.wasm
Renders the AST to PDF bytes and SVG elements ~5 MB

Both run inside a Web Worker to avoid blocking the main thread. This is critical β€” Typst compilation can take 200-400ms even for a single-page resume, and you don't want that on the UI thread.

Worker Initialization

// frontend/src/features/template-renderer/hooks/useTypstCompiler.ts
const workerRef = useRef<Worker>();

useEffect(() => {
  const worker = new Worker(
    new URL('../worker/typst.worker.ts', import.meta.url),
    { type: 'module' }
  );

  worker.postMessage({ type: 'init' });
  workerRef.current = worker;

  return () => worker.terminate();
}, []);

The worker loads the WASM binaries, fetches font files from CDN (Roboto, NotoSansCJK, Font Awesome), and preloads Typst template files from the /public/templates/

directory.

Compilation Message Protocol

The main thread and worker communicate via a simple message protocol:

Main Thread                    Web Worker
     β”‚                              β”‚
     │──── set_source ────────────▢ β”‚  (update .typ source)
     │──── compile (id: 7) ───────▢ β”‚  (trigger compilation)
     β”‚                              β”‚
     β”‚  ... user types, triggers    β”‚
     β”‚      another compile ...     β”‚
     │──── compile (id: 8) ───────▢ β”‚
     β”‚                              β”‚
     │◀─── compile_done (id: 7) ─── β”‚  ← stale, ignored
     │◀─── compile_done (id: 8) ─── β”‚  ← current, rendered

Each compile

message carries a monotonically incrementing ID. When the worker finishes, it echoes the ID back. If the ID doesn't match the latest request, the result is discarded β€” a simple form of stale-result rejection without AbortController.

Template Mock Injection

Typst templates typically use #import

directives to reference other files. In the WASM sandbox, there's no file system access, so the worker strips these imports and injects mock implementations:

// Injected into each template's source before compilation:
#let fa-icon(name, fill: black) = {
  // Unicode character mapping β€” no external font needed
  let icons = (
    "github": "\u{f09b}",
    "linkedin": "\u{f08c}",
    "envelope": "\u{f0e0}",
    // ...
  )
  text(fill: fill, raw(icons.at(name, default: "")))
}

#let linguify(key, default: none, ..args) = { default }

The Editor: ContentEditable Meets Markdown #

The editing experience is block-based β€” similar to Notion. Each block is a heading, list item, or paragraph. The twist is that every block supports two editing modes:

WYSIWYG Mode (contentEditable)

A contenteditable

div with formatting (bold, color, font size). The challenge with contentEditable is selection preservation across React re-renders. The solution:

// frontend/src/features/editor/utils/domUtils.ts
function saveSelection(container: HTMLElement): SelectionState | null {
  const selection = window.getSelection();
  if (!selection || !selection.rangeCount) return null;

  // Walk the DOM tree to find the caret position by character offset
  const nodeStack: Node[] = [];
  const walker = document.createTreeWalker(
    container,
    NodeFilter.SHOW_TEXT,
    null
  );
  // ... build path to current node and offset within it
  return { nodePath, offset };
}

function restoreSelection(
  container: HTMLElement,
  state: SelectionState
): void {
  // Walk the stored path through child nodes to reach the target
  // Then set the caret at the stored offset
}

Raw Markdown Mode

A hidden <textarea>

activates when you click or press Enter in the margin zone next to a block. Type raw markdown, commit with Enter, cancel with Escape.

**Senior Engineer** at Acme Corp
- Led a team of **5 engineers**
- Built [the platform]{#0075de}

The format uses custom extensions: [text]{#color}

for colored text and [text]{size:14pt}

for font sizing. These map to Tailwind-style inline styles in the rendered output and to Typst markup in the generated source.

Auto-Detection on Input

Typing #

, ##

, ###

, or -

at the start of a block converts its type automatically β€” no toolbar clicks needed.

Typst Code Generation #

The editor state (a tree of blocks) is converted to Typst source code via template-specific generators:

// frontend/src/features/template-renderer/generators/westernResume.ts
export function generateWesternResume(state: EditorState): string {
  const lines: string[] = [];

  // Header with personal info
  lines.push(`#set page(margin: (top: 1.5cm, bottom: 1.5cm))`);
  lines.push(`#align(center)[`);
  lines.push(`  = ${escape(state.personalInfo.name)}`);
  lines.push(`  ${escape(state.personalInfo.email)} | ${escape(state.personalInfo.phone)}`);
  lines.push(`]`);

  // Sections (h1) β†’ entries (h2) β†’ roles (h3)
  for (const section of state.sections) {
    lines.push(`== ${escape(section.title)}`);
    for (const entry of section.entries) {
      lines.push(`#resume-entry(`);
      lines.push(`  title: [${escape(entry.title)}],`);
      lines.push(`  right: [${escape(entry.right)}],`);
      lines.push(`)`);
      // Rich text items as Typst markup
      for (const item of entry.items) {
        lines.push(`  - ${renderRichText(item.content)}`);
      }
    }
  }

  return lines.join('\n');
}

The generator translates rich text formatting into native Typst markup:

Editor Format Typst Output
**bold text**
#strong[bold text]
[colored text]{#0075de}
#text(fill: rgb("#0075de"))[colored text]
[text]{size:14pt}
#text(size: 14pt)[text]

Persistent State Without a Backend #

All state lives in IndexedDB via localforage:

// frontend/src/shared/utils/storage.ts
import localforage from 'localforage';

const STATE_KEY = 'current_resume_state_v2';
const PHOTO_KEY = 'current_resume_photo';

export async function saveState(state: EditorState): Promise<void> {
  await localforage.setItem(STATE_KEY, state);
}

export async function loadState(): Promise<EditorState | null> {
  return await localforage.getItem(STATE_KEY);
}

export async function savePhoto(blob: Blob): Promise<void> {
  await localforage.setItem(PHOTO_KEY, blob);
}

Photos are stored separately from state to stay within IndexedDB per-key value limits (large blobs in the same record can cause performance issues). Auto-save fires on every state change with an 800ms debounce β€” frequent enough to feel instant, sparse enough to avoid thrashing.

PDF Resume Import #

Upload an existing PDF resume and SmartResume parses it back into editable blocks. This is a multi-step pipeline:

PDF File
  β”‚
  β–Ό
pdfjs-dist text extraction ─── text items with (x, y, font, size)
  β”‚
  β–Ό
Line grouping ──────────────── group text items by y-position proximity
  β”‚
  β–Ό
Header/footer removal ─────── detect and strip repeating page elements
  β”‚
  β–Ό
Line categorization ────────── classify as h1, h2, h3, bullet, or body
  β”‚
  β–Ό
Structure analysis ─────────── group into sections β†’ entries β†’ items
  β”‚
  β–Ό
Markdown assembly ──────────── reconstruct clean markdown from structure
  β”‚
  β–Ό
Editor state ───────────────── populate blocks in the editor

The parser uses heuristics rather than ML: font size thresholds for heading detection, position alignment for section boundaries, pattern matching for personal info (email regex, phone number patterns). Each template type (western, Japanese rirekisho, Japanese shokumukeirekisho) has its own parser strategy.

Design System: Notion-Inspired Warm Neutrals #

The visual design is modeled after Notion's philosophy: a blank canvas that gets out of your way. Key choices:

Warm grays(#f6f5f4

,#31302e

) with yellow-brown undertones instead of cold blue-grays - Near-black text atrgba(0,0,0,0.95)

β€” softer than#000

without sacrificing readability - Whisper borders:1px solid rgba(0,0,0,0.1)

everywhere β€” structure without visual weight - Multi-layer shadows with individual opacities never exceeding 0.05 β€” depth that's felt, not seen

The full design spec is in [markdown/DESIGN.md].

Trade-offs and Limitations #

What Works Well

Privacy: No data leaves the browser. You can verify this in DevTools Network tab β€” zero requests contain resume content. - PDF quality: Typst output is genuinely professional, on par with LaTeX. - Startup speed: No account, no signup. The app loads and you start editing.

What Could Be Better

WASM binary size: The two.wasm

files total ~13 MB. First load on slow connections is noticeable. HTTP caching and service worker pre-caching mitigate this after the first visit. - **Font **: Typst needs fonts available in the virtual filesystem. The worker fetches them from CDN on init β€” on a bad network, this can take tens of seconds. There's a 60-second timeout with a user-facing error about VPN/network issues. - contentEditable: Like every contentEditable-based editor, there are edge cases with selection, IME input, and copy-paste. The dual-mode (WYSIWYG + raw markdown) is a pragmatic escape hatch: if the rich text editor misbehaves, drop into markdown mode. - No collaboration: This is deliberate. Real-time collaboration requires a server (or WebRTC signaling), which reintroduces the privacy problem.

Try It Yourself #

git clone https://github.com/kakutixyz-ai/kakuti-resume.git
cd kakuti-resume
npm install
npm run dev

Open http://localhost:5173

. The app requires no environment variables for basic use β€” only the optional /api/feedback

endpoint needs a DISCORD_WEBHOOK_URL

.

Have you built something with WASM in the browser? What challenges did you hit with Web Workers or contentEditable? I'd appreciate your feedback on the approach.

── more in #open-source 4 stories Β· sorted by recency
── more on @react 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain β€” perfect for shipping the agent you just read about.

$git push zahid main
β†’ Live at https://your-agent.zahid.host βœ“
Get free account β†’ Pricing
from €0/mo Β· no card required
LIVE [news/building-a-privacy-f…] indexed:0 read:8min 2026-05-23 Β· β€”