DEV Community: Dev Nestio

I Built a Visual Chmod Calculator in Pure Vanilla JS — Checkboxes ↔ Numeric ↔ Symbolic, 222 Tests

Dev Nestio — Sat, 27 Jun 2026 19:10:40 +0000

Every Linux and macOS developer has typed chmod 755 on autopilot — but what does 7 actually mean? Why is 644 the default for files? And what happens to the execute bit when you set the setuid flag?

Most chmod reference pages list a table. I wanted something interactive: flip a checkbox, see the octal update. Type rwsr-xr-x, watch the checkboxes respond. So I built one — in the browser, no server, no framework.

👉 https://chmod-calculator.pages.dev

What It Does

Checkboxes for Owner / Group / Others × Read / Write / Execute — check one, everything updates instantly
Numeric input (e.g. 755) — type any valid octal, the UI reflects it
Symbolic input (e.g. rwxr-xr-x) — edit the string, checkboxes follow
Octal display (e.g. 0755) with the full 4-digit form
Binary display (e.g. 111 101 101) — see exactly which bits are set
Special bits — Setuid (4000), Setgid (2000), Sticky (1000) as labeled cards with descriptions
Presets — one click for 644, 755, 777, 600, 700, 400, 4755, 1777
chmod command generator with an editable filename field and a copy button
Zero external dependencies — single HTML file, works offline

The Core Logic

Unix permissions are a 12-bit integer. The lower 9 bits are the familiar rwx groups. Bits 9–11 are the special flags.

Bit layout (octal prefix → lower 9 bits):
  bit 11 (0x800) = setuid
  bit 10 (0x400) = setgid
  bit  9 (0x200) = sticky
  bits 8-6       = owner  r/w/x  (0x100, 0x80, 0x40)
  bits 5-3       = group  r/w/x  (0x20,  0x10, 0x08)
  bits 2-0       = others r/w/x  (0x04,  0x02, 0x01)

Numeric → Symbolic

function modeToSymbolic(mode) {
  const bits = [
    [0x100, 'r'], [0x80, 'w'], [0x40, 'x'],
    [0x20,  'r'], [0x10, 'w'], [0x08, 'x'],
    [0x04,  'r'], [0x02, 'w'], [0x01, 'x']
  ];
  let sym = '';
  for (let i = 0; i < 9; i++) {
    sym += (mode & bits[i][0]) ? bits[i][1] : '-';
  }
  const setuid = !!(mode & 0x800);
  const setgid = !!(mode & 0x400);
  const sticky = !!(mode & 0x200);

  // Special bits replace the execute position
  if (setuid) sym = sym.slice(0, 2) + ((mode & 0x40) ? 's' : 'S') + sym.slice(3);
  if (setgid) sym = sym.slice(0, 5) + ((mode & 0x08) ? 's' : 'S') + sym.slice(6);
  if (sticky) sym = sym.slice(0, 8) + ((mode & 0x01) ? 't' : 'T');

  return sym;
}

The special bit substitution follows the POSIX convention: lowercase s/t when the execute bit is also set, uppercase S/T when it is not. This lets ls -l pack two pieces of information into one character.

Symbolic → Numeric

function symbolicToMode(sym) {
  if (!/^[rwxsStT-]{9}$/.test(sym)) return null;

  const values = [0x100, 0x80, 0x40, 0x20, 0x10, 0x08, 0x04, 0x02, 0x01];
  let mode = 0;
  for (let i = 0; i < 9; i++) {
    const c = sym[i];
    if (c === 'r' || c === 'w' || c === 'x') {
      mode |= values[i];
    } else if (c === 's') {
      mode |= values[i];                         // execute bit
      if (i === 2) mode |= 0x800;               // setuid
      else if (i === 5) mode |= 0x400;          // setgid
    } else if (c === 'S') {
      if (i === 2) mode |= 0x800;               // setuid without execute
      else if (i === 5) mode |= 0x400;
    } else if (c === 't') {
      mode |= values[i];                         // others execute
      mode |= 0x200;                             // sticky
    } else if (c === 'T') {
      mode |= 0x200;                             // sticky without execute
    }
  }
  return mode;
}

Position matters: s at index 2 is setuid, s at index 5 is setgid. The regex guard [rwxsStT-]{9} rejects anything that can't be a valid symbolic string before any bit-twiddling begins.

Why `s` vs `S` — and `t` vs `T`

chmod 4755 /usr/bin/sudo   →  rwsr-xr-x   (setuid, owner exec set)
chmod 4644 myfile          →  rwSr--r--   (setuid, owner exec NOT set)
chmod 1777 /tmp            →  rwxrwxrwt   (sticky, others exec set)
chmod 1776 /tmp            →  rwxrwxrwT   (sticky, others exec NOT set)

The uppercase form is a warning: the special bit is set but has no execute bit to "attach" to — which is unusual and often unintentional.

Octal formatting

function modeToOctal(mode) {
  const special = (mode >> 9) & 7;
  const owner   = (mode >> 6) & 7;
  const group   = (mode >> 3) & 7;
  const other   = mode & 7;
  // Prefix 0 when no special bits, otherwise lead with special digit
  return special ? `${special}${owner}${group}${other}` : `0${owner}${group}${other}`;
}

0644 and 4755 both have 4 characters. The leading 0 for a plain mode signals "no special bits" without adding a fifth digit.

Binary representation

function modeToBinary(mode) {
  const owner = ((mode >> 6) & 7).toString(2).padStart(3, '0');
  const group = ((mode >> 3) & 7).toString(2).padStart(3, '0');
  const other = (mode & 7).toString(2).padStart(3, '0');
  return `${owner} ${group} ${other}`;
}
// 755 → "111 101 101"
// 644 → "110 100 100"

Three groups of three bits, each padded to width 3. This makes the r/w/x mapping visually obvious — a 1 in position 0 of each group means read, position 1 means write, position 2 means execute.

Keeping All Representations in Sync

The state is a single integer currentMode. Every input (checkbox, numeric field, symbolic field, preset button) calls updateFromMode(mode) after computing the new mode value. That function pushes the new state to every output element — no separate reconciliation loop needed.

let currentMode = 0o644;

function updateFromMode(mode) {
  currentMode = mode;
  // Update all 12 checkboxes
  document.getElementById('ur').checked = !!(mode & 0x100);
  // ... and the rest
  // Update numeric input
  document.getElementById('numInput').value = modeToOctal(mode).replace(/^0/, '');
  // Update symbolic input
  document.getElementById('symInput').value = modeToSymbolic(mode);
  // Update display cards and chmod command
}

A suppressUpdate flag prevents re-entrant updates when the function itself sets input values (which would otherwise trigger their input event handlers).

Common Permissions Reference

Mode	Symbolic	Typical use
644	rw-r--r--	Regular files (web content, configs)
755	rwxr-xr-x	Directories, executables
600	rw-------	Private keys, .env files
700	rwx------	Private directories
400	r--------	Read-only secrets
4755	rwsr-xr-x	Setuid executables (sudo, ping)
1777	rwxrwxrwt	Sticky directories (/tmp)

Testing Without a Framework

222 tests, no test runner, no dependencies — just Node.js built-ins:

let passed = 0, failed = 0;

function eq(a, b, label) {
  if (a === b) { console.log(`  ✓ ${label}`); passed++; }
  else {
    console.error(`  ✗ ${label}\n    got:      ${JSON.stringify(a)}\n    expected: ${JSON.stringify(b)}`);
    failed++;
  }
}

// Round-trip test: mode → symbolic → mode
function roundTrip(mode, label) {
  const sym = modeToSymbolic(mode);
  const back = symbolicToMode(sym);
  eq(back, mode, `round-trip ${label}`);
}

roundTrip(0o755, '755');
roundTrip(0o4755, '4755 setuid');
roundTrip(0o1777, '1777 sticky');
// ... 18 round-trips total

The round-trip tests (symbolic → numeric → symbolic → numeric) catch any asymmetry between the encode and decode paths. If they both have the same bug, round-trips still pass — so I also test both directions against known expected values.

All 222 tests PASSED

Try It

https://chmod-calculator.pages.dev

Source is a single self-contained HTML file — open DevTools, read the script block, and you have the full implementation. Part of devnestio, a collection of browser-only developer tools.

I Built a Browser-Only HTML Entity Encoder/Decoder — Named, Decimal & Hex, 246 Tests

Dev Nestio — Sat, 27 Jun 2026 19:00:47 +0000

Every developer has hit this: you need to escape <, >, &, and quotes before dropping user input into HTML — or you're staring at mangled text full of & and need to convert it back. Most online tools do the basics, but fall short on the full HTML5 named entity set or force you to choose between three encoding formats.

I built one that handles all three formats, 253 named entities, and decodes all of them with a single regex pass — entirely in the browser, no server, no framework.

👉 https://html-entity-encoder.pages.dev

What It Does

Encode: text → HTML entities in three modes
- Named — é → é, © → ©, π → π
- Decimal — é → é, © → ©
- Hex — é → é, © → ©
Decode: all three entity formats back to plain text
253 HTML5 named entities — Latin-1 Supplement, Latin Extended-A, Greek, Math, Arrows, Punctuation, Currency, Symbols
Real-time: output updates on every keystroke
Quick Reference: collapsible table you can click to insert characters
Swap, Copy, Clear, Sample buttons
Zero external dependencies — single HTML file, works offline

The Core: Encoding in Three Modes

The encoding logic iterates over Unicode code points (not UTF-16 code units), which is essential for handling emoji and characters outside the BMP:

const ALWAYS_ENCODE = new Set(['&', '<', '>', '"', "'"]);

function encode(text, mode) {
  if (!text) return '';
  const result = [];
  for (const ch of text) {          // for...of iterates code points
    const cp = ch.codePointAt(0);
    const mustEncode = ALWAYS_ENCODE.has(ch) || cp > 127;
    if (!mustEncode) { result.push(ch); continue; }

    if (mode === 'named') {
      result.push(CHAR_TO_ENTITY[ch] || `&#${cp};`);
    } else if (mode === 'decimal') {
      result.push(`&#${cp};`);
    } else {                        // hex
      result.push(`&#x${cp.toString(16).toUpperCase()};`);
    }
  }
  return result.join('');
}

The for...of loop over a string yields Unicode code points. A for loop with index would break on any character outside the Basic Multilingual Plane — emoji like 😀 are encoded as surrogate pairs in UTF-16, so a naive str[i] approach would emit two separate (invalid) entities for a single character.

Why &#N; fallback in named mode? Because the 253 named entities don't cover everything. A character like 😀 (U+1F600) has no HTML5 named form, so decimal is the only option.

The Decode Regex

One regex handles all three entity formats in a single pass:

function decode(text) {
  if (!text) return '';
  return text.replace(
    /&([a-zA-Z][a-zA-Z0-9]*);|&#([0-9]+);|&#[xX]([0-9a-fA-F]+);/g,
    (match, name, dec, hex) => {
      try {
        if (name !== undefined)
          return Object.prototype.hasOwnProperty.call(ENTITY_TO_CHAR, name)
            ? ENTITY_TO_CHAR[name] : match;
        if (dec !== undefined)
          return String.fromCodePoint(parseInt(dec, 10));
        if (hex !== undefined)
          return String.fromCodePoint(parseInt(hex, 16));
      } catch (_) {}
      return match;
    }
  );
}

Three alternation groups, each capturing a different entity format. The named entity lookup uses hasOwnProperty explicitly to guard against prototype pollution — toString, constructor, __proto__ are technically valid entity name shapes, so a direct ENTITY_TO_CHAR[name] lookup could be exploited to return unexpected values from the prototype chain.

The hex branch accepts both &#x...; and &#X...; (the [xX] in the regex) — the HTML5 spec allows both, even though lowercase is conventional.

Building the Entity Maps

The decode map is the source of truth: ENTITY_TO_CHAR maps each name string to its Unicode character. Then the encode map is derived by inverting it:

const CHAR_TO_ENTITY = {};
(function buildCharMap() {
  // First pass: reverse all entries
  for (const [name, ch] of Object.entries(ENTITY_TO_CHAR)) {
    if (!CHAR_TO_ENTITY[ch]) CHAR_TO_ENTITY[ch] = `&${name};`;
  }
  // Second pass: force canonical preferred names for ambiguous chars
  const preferred = {
    '"': '&quot;', '&': '&amp;', "'": '&apos;',
    '<': '&lt;',   '>': '&gt;',  ' ': '&nbsp;',
    '©': '&copy;', '®': '&reg;', '™': '&trade;',
    '€': '&euro;', '×': '&times;', '÷': '&divide;'
  };
  Object.assign(CHAR_TO_ENTITY, preferred);
})();

Some characters have multiple named forms in HTML5. For example, ' maps to both ' (from XHTML) and &squot; — the second pass pins canonical names so the encoder always outputs the most recognizable form.

What's in the 253-entity Map

Category	Count	Examples
HTML special	5	`&` `<` `>` `"` `'`
Latin-1 Supplement	96	`é` `ñ` `©` `€`
Latin Extended-A	5	`&OElig;` `&oelig;` `&Scaron;`
Greek	49	`α` `π` `Σ` `Ω`
Mathematical	37	`∞` `≠` `≤` `∑` `√`
Arrows	11	`→` `←` `⇔` `&crarr;`
Punctuation	20	`—` `–` `…` `“`
Misc Symbols	10+	`™` `•` `&spades;` `&hearts;`
Currency	5	`€` `£` `¥` `¢`

Testing: 246 Cases, No Framework

246 tests across 26 sections, built on a two-function inline runner:

let passed = 0, failed = 0;

function eq(a, b, label) {
  if (a === b) { console.log(`  ✓ ${label}`); passed++; }
  else {
    console.error(`  ✗ ${label}\n    got:      ${JSON.stringify(a)}\n    expected: ${JSON.stringify(b)}`);
    failed++;
  }
}

Section	Tests	What's covered
Entity map coverage	12	Size ≥ 250, key entries exist
Encode HTML specials (named/decimal/hex)	23	`& < > " '` in all modes
Encode Latin extended (all modes)	25	`© € é ñ ü ± ° ½`
Encode Greek (all modes)	14	`α β γ π Σ Ω`
Encode math & symbols	11	`∞ ≠ ≤ √ → • — …`
ASCII passthrough	8	Letters, digits, misc symbols
Encode mixed strings	7	XSS payloads, café, résumé
Decode named entities	20	All common named entities
Decode decimal entities	10	`&` through `π`
Decode hex (lowercase/uppercase X)	15	`<` and `&#X3C;` forms
Decode mixed strings	8	Full HTML tags, price strings
Decode edge cases	10	Unknown entities, no semicolon, empty
Round-trip (encode→decode)	30	10 strings × 3 modes
Double-encoding prevention	2	`&` → `&amp;`
Unicode correctness	7	U+0000, U+0041, U+2665
Entity map value checks	10	Known char values
Misc symbols encode	8	`♠ ♥ ♦ ♣ ⇒ ∑`
Less common entities	13	`&OElig;` `•` `&permil;`
Whitespace entities	5	`&ensp;` `&emsp;` `&zwnj;`
Hex uppercase digits	4	`Ä` `Ü`
Non-BMP encode/decode	4	😀 decimal + hex round-trip

Run with npm test.

A Subtle Edge Case: Prototype Pollution in Decode

The named entity lookup is written as:

Object.prototype.hasOwnProperty.call(ENTITY_TO_CHAR, name)
  ? ENTITY_TO_CHAR[name]
  : match

rather than the simpler ENTITY_TO_CHAR[name]. Why? Because name comes from user-supplied text via the regex match. If someone passes &constructor; or &__proto__; as input, a direct bracket lookup would walk the prototype chain and return a function object or the prototype itself — then String.fromCodePoint on a non-integer would throw, but that's after already leaking prototype state.

The hasOwnProperty check ensures we only return values that are explicitly in the entity map, not inherited from Object.prototype.

Try It

https://html-entity-encoder.pages.dev

Single HTML file, no build step. Open DevTools and read the source — everything is there.

Also part of devnestio — a growing collection of zero-dependency browser tools for developers.

Built with: vanilla JS, the HTML5 named character references spec, and an unreasonable number of Greek letters.

I Built a Color Picker & Palette Generator in Pure Vanilla JS — No Libraries, 187 Tests

Dev Nestio — Sat, 27 Jun 2026 18:49:03 +0000

Every designer and developer has been there: you have a brand color and need a palette that actually works — complementary, analogous, triadic, or something in between. Most tools either require an account or pull in a heavy design library. I built one that runs entirely in the browser with zero dependencies.

The result: Color Picker & Palette Generator — a free, client-side tool that converts colors between four formats and generates six types of palettes instantly.

👉 https://color-picker-62x.pages.dev

What It Does

Native color picker (<input type="color">) — no custom UI needed, OS-native and accessible
Real-time conversion between HEX, RGB, HSL, and HSV
Click any value to copy — format strings like hsl(243, 100%, 70%) go straight to your clipboard
Six palette types: Complementary, Analogous, Triadic, Tetradic, Split-Complementary, Monochromatic (6 shades)
Click any swatch to copy its hex code
Random color button for quick inspiration
Zero external dependencies, works offline

The Color Math

The core is pure math — no canvas tricks, no DOM manipulation for conversion. Every format conversion is a direct function.

HEX ↔ RGB

Straightforward bit-shifting:

function hexToRgb(hex) {
  const h = hex.replace('#', '');
  const full = h.length === 3
    ? h.split('').map(c => c + c).join('')
    : h;
  const n = parseInt(full, 16);
  return { r: (n >> 16) & 0xff, g: (n >> 8) & 0xff, b: n & 0xff };
}

function rgbToHex({ r, g, b }) {
  return '#' + [r, g, b]
    .map(v => Math.round(v).toString(16).padStart(2, '0'))
    .join('');
}

Short hex (#fff) is expanded by doubling each character before parsing.

RGB → HSL

The trickier conversion — HSL is the most useful space for palette generation because hue rotations map directly to color relationships:

function rgbToHsl({ r, g, b }) {
  const rn = r / 255, gn = g / 255, bn = b / 255;
  const max = Math.max(rn, gn, bn), min = Math.min(rn, gn, bn);
  const l = (max + min) / 2;
  let h = 0, s = 0;
  if (max !== min) {
    const d = max - min;
    s = d / (l > 0.5 ? 2 - max - min : max + min);
    switch (max) {
      case rn: h = ((gn - bn) / d + (gn < bn ? 6 : 0)) / 6; break;
      case gn: h = ((bn - rn) / d + 2) / 6; break;
      case bn: h = ((rn - gn) / d + 4) / 6; break;
    }
  }
  return { h: Math.round(h * 360), s: Math.round(s * 100), l: Math.round(l * 100) };
}

The saturation formula switches between two variants based on lightness — that's the subtle part. When l > 0.5, you're in the upper half of the HSL cylinder and the denominator changes.

RGB → HSV

HSV (also called HSB) is different from HSL in how it handles brightness. A fully saturated red at V=100 is rgb(255,0,0); at V=50 it's rgb(128,0,0). That makes HSV natural for adjusting brightness without washing out to white (which HSL's lightness does at L=100).

function rgbToHsv({ r, g, b }) {
  const rn = r / 255, gn = g / 255, bn = b / 255;
  const max = Math.max(rn, gn, bn), min = Math.min(rn, gn, bn);
  const d = max - min;
  let h = 0;
  const s = max === 0 ? 0 : d / max;
  const v = max;
  if (d !== 0) {
    switch (max) {
      case rn: h = ((gn - bn) / d + (gn < bn ? 6 : 0)) / 6; break;
      case gn: h = ((bn - rn) / d + 2) / 6; break;
      case bn: h = ((rn - gn) / d + 4) / 6; break;
    }
  }
  return { h: Math.round(h * 360), s: Math.round(s * 100), v: Math.round(v * 100) };
}

Palette Generation

All palettes derive from HSL hue rotation — that's why HSL is the right working space for this.

Hue normalization

Before any rotation, normalize hue to [0, 360):

function normalizeHue(h) { return ((h % 360) + 360) % 360; }

The double-mod pattern handles negative inputs correctly (e.g., normalizeHue(-60) → 300).

The six palette types

Type	Colors	Logic
Complementary	2	hue + 180°
Analogous	5	hue ± 30°, ± 60°
Triadic	3	hue + 0°, 120°, 240°
Tetradic	4	hue + 0°, 90°, 180°, 270°
Split-Complementary	3	hue + 0°, 150°, 210°
Monochromatic	6	same hue/saturation, lightness 10–85%

function paletteTriadic(hex) {
  const { h, s, l } = hslFromHex(hex);
  return [0, 120, 240].map(offset =>
    hexFromHsl(normalizeHue(h + offset), s, l)
  );
}

function paletteMonochromatic(hex) {
  const { h, s } = hslFromHex(hex);
  return [10, 25, 40, 55, 70, 85].map(l => hexFromHsl(h, s, l));
}

The monochromatic palette fixes hue and saturation, stepping lightness from dark to light. Six evenly-spaced steps from L=10 to L=85 gives a usable range across backgrounds and text.

Clipboard Copy

Two paths — modern async API with a document.execCommand fallback:

function copyToClipboard(text) {
  try {
    navigator.clipboard.writeText(text)
      .then(() => showToast('Copied: ' + text));
  } catch (e) {
    const ta = document.createElement('textarea');
    ta.value = text;
    ta.style.position = 'fixed';
    ta.style.opacity = '0';
    document.body.appendChild(ta);
    ta.select();
    try { document.execCommand('copy'); } catch (_) {}
    document.body.removeChild(ta);
    showToast('Copied: ' + text);
  }
}

The fallback matters because navigator.clipboard requires HTTPS and a focused document — both guaranteed in production, but not always in local dev.

Testing: 187 Cases, No Framework

The test suite covers every conversion function, round-trips, palette shapes, and edge cases — 25 sections, built with a 30-line inline runner.

Section	Tests	What's covered
hexToRgb	12	6-char, 3-char, known vectors
rgbToHex	10	known vectors, padding
rgbToHsl	12	primaries, achromatic, bounds
hslToRgb	10	primaries, achromatic, boundary hues
rgbToHsv	10	primaries, white, black, gray
normalizeHue	10	negative, >360, wrapping
HEX round-trip	8	hex → rgb → hex identity
RGB→HSL→RGB round-trip	8	Δ ≤ 1 per channel
paletteComplementary	8	count, hue offset, input preserved
paletteAnalogous	8	count, center matches input, hue steps
paletteTriadic	8	count, hue spacing 120°
paletteTetradic	8	count, hue spacing 90°
paletteSplitComplementary	8	count, offsets 150°/210°
paletteMonochromatic	8	count, same hue/s, lightness order
hslFromHex helper	6	known outputs
hexFromHsl helper	6	known outputs
rgbToHsl edge cases	6	achromatic, near-white/black
hslToRgb boundary	6	h=360, l=0/100, achromatic
Palette count checks	6	all 6 types
Total palette colors	4	2+5+3+4+3+6 = 23
Hue arithmetic	6	complement hues verified
rgbToHsv consistency	6	yellow, gray, cyan
HSL→RGB→HSV chain	6	hue preserved across chain
Palette hue spacing	6	triadic 120°, tetradic 90°
Format string construction	6	regex, range checks

No Jest, no Mocha, no assert module — just:

function assert(condition, label) {
  if (condition) { console.log(`  ✓ ${label}`); passed++; }
  else { console.error(`  ✗ ${label}`); failed++; }
}

Run with npm test.

The Tricky Edge Case

The rgbToHsl saturation formula has a branch that trips people up:

s = d / (l > 0.5 ? 2 - max - min : max + min);

When lightness exceeds 0.5, the formula switches denominator. It took me three wrong implementations before I traced it back to the original HSL cylindrical model definition. The two-segment formula ensures saturation reaches 100% at both the brightest and darkest extremes.

Try It

https://color-picker-62x.pages.dev

Single index.html, no build step, no framework. Open DevTools and read the source.

Also part of devnestio — a collection of zero-dependency developer tools.

Built with: vanilla JS, the HSL spec, and a lot of hue rotation math.

I Built a QR Code Generator in Pure Vanilla JS — No Libraries, No Server, 202 Tests

Dev Nestio — Sat, 27 Jun 2026 18:33:16 +0000

QR codes look like magic — a grid of black and white squares that encodes anything from a URL to a business card. But how do they actually work? I decided to find out the hard way: implement the full QR Code Model 2 algorithm in vanilla JavaScript, zero external dependencies.

The result: QR Code Generator — a free, client-side tool that generates QR codes from any text or URL.

👉 https://qr-code-generator-e83.pages.dev

Why No Libraries?

I maintain a collection of browser-only developer tools at devnestio. Every tool has the same rule: zero external dependencies. No npm installs, no CDN scripts, no servers.

For most tools (JSON diff, Base64 encoder, UUID generator) that's easy. QR codes are different. The spec is a 126-page ISO document. Most developers just npm install qrcode and call it a day.

But writing it from scratch taught me more about error-correcting codes, Galois field arithmetic, and matrix encoding than I ever expected. Worth every hour.

What the Tool Does

Real-time generation as you type (debounced at 80ms)
Size selector — 128 × 128, 256 × 256, or 512 × 512 pixels
Error correction level — L (7%), M (15%), Q (25%), H (30%)
Color picker — any foreground and background color
PNG download via canvas
SVG download with crisp vector output at any scale

How QR Codes Actually Work

QR Code Model 2 (the standard you see everywhere) has six major steps. Here's the short version:

1. Data Encoding

Text gets encoded into one of three modes based on content:

Numeric (0-9): packs 3 digits into 10 bits — most compact
Alphanumeric (0-9 A-Z $%*+-./:space): 2 chars into 11 bits
Byte (everything else): UTF-8, one byte per 8 bits

The encoder picks the mode automatically and finds the minimum QR version (1–40) that fits the data.

function detectMode(text) {
  if (/^\d+$/.test(text)) return NUMERIC_MODE;
  if (text.split('').every(c => ALPHANUMS.includes(c))) return ALPHANUM_MODE;
  return BYTE_MODE;
}

2. Reed-Solomon Error Correction

This is the hard part. QR codes can survive up to 30% damage (at ECL H) because of Reed-Solomon codes — the same algorithm used in CDs, DVDs, and deep-space transmissions.

RS encoding requires arithmetic in Galois Field GF(256), where numbers wrap around at 256 using polynomial division mod x⁸ + x⁴ + x³ + x² + 1 (0x11d):

const GF = (() => {
  const EXP = new Uint8Array(512);
  const LOG  = new Uint8Array(256);
  let x = 1;
  for (let i = 0; i < 255; i++) {
    EXP[i] = x;
    LOG[x] = i;
    x <<= 1;
    if (x & 0x100) x ^= 0x11d; // reduce mod primitive polynomial
  }
  for (let i = 255; i < 512; i++) EXP[i] = EXP[i - 255];
  return {
    mul(a, b) { return (a === 0 || b === 0) ? 0 : EXP[LOG[a] + LOG[b]]; },
    // ...
  };
})();

Multiplication in GF(256) becomes table lookups: mul(a, b) = EXP[LOG[a] + LOG[b]]. The EXP and LOG tables are precomputed once, making the encoder fast.

3. Data Interleaving

For larger QR versions, data is split into multiple blocks, each with its own RS error-correction codewords. The blocks are then interleaved — one byte from block 1, one from block 2, etc. — so physical damage (a scratch across the code) hits different blocks and can be recovered.

4. Matrix Construction

A QR code matrix (21×21 for version 1, up to 177×177 for version 40) has:

Finder patterns — the three 7×7 squares in the corners
Alignment patterns — smaller squares for versions 2+
Timing patterns — alternating dark/light rows/columns for calibration
Format information — ECL and mask pattern, BCH(15,5) encoded
Version information — for versions 7+, BCH(18,6) encoded
Data modules — placed in a specific zigzag path

5. Masking

QR scanners struggle with large solid areas or repetitive patterns. The spec defines 8 mask functions (e.g., (row + col) % 2 === 0). The encoder tries all 8, scores each using a 4-rule penalty system, and picks the lowest-penalty mask:

const MASK_FNS = [
  (r,c) => (r+c)%2===0,
  (r,c) => r%2===0,
  (r,c) => c%3===0,
  (r,c) => (r+c)%3===0,
  (r,c) => (Math.floor(r/2)+Math.floor(c/3))%2===0,
  (r,c) => (r*c)%2+(r*c)%3===0,
  (r,c) => ((r*c)%2+(r*c)%3)%2===0,
  (r,c) => ((r+c)%2+(r*c)%3)%2===0
];

6. Format Info Placement

The chosen ECL and mask index are BCH-encoded into a 15-bit format string and written to reserved areas around the top-left finder pattern and mirrored at the top-right and bottom-left finders. I precomputed all 32 possible values to keep the runtime code simple.

Testing: 202 Cases, Node.js Built-in Only

The test suite covers every layer of the algorithm:

Section	Tests	What's covered
GF(256) arithmetic	14	mul, div, pow, inv, tables
RS generator	8	polynomial degree, known vector
Mode detection	12	numeric/alphanumeric/byte edge cases
UTF-8 encoding	10	ASCII, 2/3/4-byte codepoints
Data capacity table	10	versions 1–40, all 4 ECL levels
charCountBits	9	bit width transitions at v9/v26
encodeData version selection	12	min version, overflow, max inputs
BitStream	8	append, byte packing, alignment
generateQR shape	12	matrix dimensions, null inputs
Module values	10	0/1 only, finder pattern positions
Version sizes	8	size = version × 4 + 17
Mask patterns	8	all 8 mask functions
Version info BCH	6	known spec values (v7–v10, v40)
Format strings	6	known spec values (all ECL levels)
Alignment positions	6	v1, v2, v7, v40
Codeword interleaving	6	total length = data + EC
ECL level comparisons	8	same text, increasing ECL = higher ver
Known RS vector	6	exact byte match from QR spec
Finder pattern modules	8	dark/light positions verified
Edge cases	6	emoji, long URLs, whitespace
ECL stress	6	version ordering across L/M/Q/H
Null input handling	4	null/undefined/empty/overflow

No Jest, no Mocha, no assert module — just a 30-line test runner I wrote inline.

The Hardest Bug

The format info placement had a subtle off-by-one. The spec places bits 0–5 of the 15-bit format word in rows 0–5 of column 8, bit 7 in row 7, and bit 8 in row 8. I had the bit ordering reversed for the horizontal vs vertical copies, which produced valid-looking (but wrong) format areas.

The fix: explicitly write each position separately rather than looping symmetrically.

Try It

https://qr-code-generator-e83.pages.dev

The full source is a single index.html — open DevTools and read through it. No build step, no framework, no minification. It's all there.

Also part of devnestio — a growing collection of zero-dependency developer tools.

Built with: vanilla JS, a copy of the QR Code ISO standard, and too much coffee.

I Built a Browser-Only YAML Formatter & Validator (No Dependencies, Works Offline)

Dev Nestio — Sat, 27 Jun 2026 17:57:23 +0000

If you work with Kubernetes manifests, Docker Compose files, or GitHub Actions workflows, you know the pain: you kubectl apply something, and only then discover there's a bad indentation on line 47.

I built a YAML Formatter & Validator that catches those errors before you ever leave your browser tab.

👉 https://devnestio.pages.dev/yaml-formatter/

Why Yet Another YAML Tool?

Most online YAML validators do the job, but they send your config files to a server. When you're working with cloud infrastructure configs — Kubernetes secrets, Helm values, Terraform variables — sending those to a third-party feels wrong.

This tool runs entirely in the browser. No server, no external libraries, no network requests. Paste your YAML, get instant feedback.

What It Does

Format & Normalize Indentation

Paste any YAML with inconsistent indentation and it normalizes to clean 2-space format instantly:

# Input (messy indentation)
name: John
address:
 street: "123 Main St"
  city: Springfield

# Output (normalized)
name: John
address:
  street: 123 Main St
  city: Springfield

Validate with Line Numbers

When there's a syntax error, you get the exact line:

Error: bad indentation of a mapping entry at line 4, column 3

That's far more useful than kubectl apply's generic "Invalid YAML" message.

Bidirectional YAML ↔ JSON Conversion

Need your Kubernetes manifest in JSON? Or have terraform output -json output you want to convert to YAML? Both directions are one click.

# YAML
server:
  host: localhost
  port: 8080
  debug: true

{
  "server": {
    "host": "localhost",
    "port": 8080,
    "debug": true
  }
}

Minify

Strip comments and output compact JSON — handy for embedding values in CI/CD pipelines.

What YAML Structures Are Supported?

The parser is hand-written (no js-yaml), so here's the honest coverage:

✅ Nested mappings (deep Kubernetes spec nesting)
✅ Sequences (- item notation)
✅ Block scalars (| literal, > folded)
✅ Quoted strings (single and double)
✅ Inline comments
✅ Numbers, booleans, null with proper type detection
⚠️ Anchors (&anchor) and aliases (*alias) — partial support

Why No External Libraries?

js-yaml would make this trivially easy, but devnestio's rule is: single HTML file, zero external dependencies.

Two reasons:

Trust — CDN scripts could theoretically send your data somewhere. Removing all external scripts eliminates that concern.
Offline — After the first load, it works entirely from browser cache. Useful in VPN environments, airplanes, or restricted staging environments.

The parser was built with AI assistance (Claude Code sessions with detailed PRDs), validated with 114/114 passing tests.

Try It

If you work with YAML daily — k8s, Docker, GitHub Actions, Helm — keep this tab open:

👉 YAML Formatter & Validator — devnestio

All tools: https://devnestio.pages.dev

Feedback on edge cases (especially unusual YAML structures) is very welcome in the comments.

I Built a UUID Generator Using crypto.randomUUID() (Why Math.random() Is the Wrong Choice)

Dev Nestio — Sat, 27 Jun 2026 17:56:11 +0000

UUID generators are everywhere. Most of them work. But a surprising number use Math.random() under the hood, which is not cryptographically random — it's a pseudorandom number generator seeded from system time.

I built a UUID Generator using crypto.randomUUID() and crypto.getRandomValues(), with bulk generation, copy support, and format options. All in the browser.

👉 https://uuid-generator-bsf.pages.dev/

Why `crypto.randomUUID()` and Not `Math.random()`?

For UUIDs used as database primary keys or session identifiers, the uniqueness guarantee matters. Math.random() is deterministic given the same seed and is not suitable for security-sensitive random number generation.

crypto.randomUUID() uses a CSPRNG (cryptographically secure pseudorandom number generator) internally and produces a properly formatted v4 UUID per RFC 4122:

const uuid = crypto.randomUUID();
// "f47ac10b-58cc-4372-a567-0e02b2c3d479"

Position 13 is always 4 (version), and position 17 is always 8, 9, a, or b (variant). The spec guarantees this. Math.random() implementations don't.

Fallback for Older Environments

For environments without crypto.randomUUID(), there's a manual implementation using crypto.getRandomValues():

function uuidv4Fallback() {
  const b = crypto.getRandomValues(new Uint8Array(16));
  b[6] = (b[6] & 0x0f) | 0x40; // version 4
  b[8] = (b[8] & 0x3f) | 0x80; // variant
  const h = [...b].map(x => x.toString(16).padStart(2, "0"));
  return `${h.slice(0,4).join("")}-${h.slice(4,6).join("")}-${h.slice(6,8).join("")}-${h.slice(8,10).join("")}-${h.slice(10).join("")}`;
}

Setting version and variant bits manually ensures the output is a valid v4 UUID even without the high-level API.

What the Tool Includes

Single UUID generation — one click, instantly copied
Bulk generation — specify a count, get a list; useful for seeding test databases
Per-UUID copy and copy all buttons
Uppercase/lowercase toggle — some systems require uppercase UUIDs
Hyphen toggle — some APIs want f47ac10b58cc4372a5670e02b2c3d479 without separators
Fully offline — generation never touches a network

Validated Against Format Requirements

Test coverage includes:

Version bit: position 13 is always 4
Variant bit: position 17 is always 8, 9, a, or b
Total length: always 36 characters (32 hex + 4 hyphens)
Bulk generation: 10,000 UUIDs produced with zero duplicates
Uppercase/lowercase and hyphen modes produce correct output formats

58/58 passing tests.

No Framework, No External Libraries

A UUID generator has one meaningful state: the list of generated UUIDs. There's no component hierarchy, no data flow, no need for a virtual DOM. A single HTML file with ~100 lines of vanilla JS handles it.

This is devnestio's standard: single HTML file, zero CDN dependencies. After the first page load, it works entirely from browser cache — offline, on a plane, in a restricted environment.

What's Next

UUID v7 support — time-sortable UUIDs, increasingly popular as database primary keys
ULID generation — another time-ordered unique ID format
UUID validation and parsing — check whether a string is a valid UUID and what version

UUID v7 is particularly interesting: it encodes the timestamp in the first 48 bits, making them naturally sortable by creation time without a separate created_at column. Worth adding if there's demand.

Try It

For test data, mock APIs, or any time you need a few UUIDs without opening a terminal:

👉 UUID Generator — devnestio

All tools: https://devnestio.pages.dev

No ads, no server, no tracking. Just UUIDs.

I Built a Real-Time Regex Tester in the Browser (Capture Groups, Flags, No Libraries)

Dev Nestio — Sat, 27 Jun 2026 17:56:08 +0000

Writing regular expressions without instant visual feedback is like writing code without a compiler — you're guessing until you run it.

I built a Regex Tester that highlights matches in real time as you type, with full capture group support and flag toggles.

👉 https://regex-tester-dfe.pages.dev

The Problem With Most Regex Tools

Most online regex testers work fine, but they require a button press to see results. You type your pattern, fill in test text, then click "Match" or "Test." When you're iterating quickly on a complex pattern, that friction adds up.

Real-time feedback changes how you work with regex.

What It Does

Live Match Highlighting

The moment you type a character in the pattern field, matches highlight in the test string. No button needed.

Test string: "Hello World 2026-06-17"
Pattern: \d{4}-\d{2}-\d{2}

→ "2026-06-17" highlights instantly

Multiple matches get distinct colors so you can see at a glance whether your pattern catches the right things.

Capture Group Inspector

See exactly which text each group captured:

Pattern: (\d{4})-(\d{2})-(\d{2})
Test:    "Today is 2026-06-17"

Match #1: "2026-06-17"
  Group 1: "2026"
  Group 2: "06"
  Group 3: "17"

Named capture groups ((?<year>\d{4})) work too — essential for log parsing and data extraction patterns.

Flag Toggles (With Instant Preview)

Toggle flags with one click; results update immediately:

Flag	Effect
`g`	Global — match all occurrences
`i`	Case-insensitive
`m`	Multiline — `^`/`$` match per line
`s`	Dotall — `.` matches newlines
`u`	Unicode mode

Pattern: \d+  |  Test: "abc 123 def 456"

g off → only "123" highlights
g on  → both "123" and "456" highlight

Match Count & Error Display

Total match count updates live. If your pattern has a syntax error, you see it immediately:

Pattern: (unclosed group
→ "Invalid regex: Unterminated group"

Real-World Examples

Extract IPs from logs:

Test:    "2026-06-17 12:34:56 [ERROR] Request from 192.168.1.100"
Pattern: (\d{1,3}\.){3}\d{1,3}

→ "192.168.1.100" highlighted

Parse URL segments:

Test:    "https://example.com/users/42/profile"
Pattern: /users/(?<id>\d+)/(?<page>\w+)

Group id: "42"
Group page: "profile"

Validate email format:

Pattern: ^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$
Flags: i

"user@example.com" → match ✅
"not-an-email"     → no match ❌

Under the Hood

The highlight system uses contenteditable with span-based coloring — no framework, pure vanilla JS. The key challenge was preserving cursor position on every keystroke while re-rendering the highlighted DOM. The PRD I gave the AI agent explicitly forbade execCommand and required cursor position preservation.

Built with AI-assisted implementation, validated with 37/37 passing tests.

Try It

Whether you're building log parsers, input validators, or text extractors — keep this one bookmarked:

👉 Regex Tester — devnestio

All tools: https://devnestio.pages.dev

Runs entirely in your browser. No data leaves your machine.

I Built a JWT Decoder That Never Sends Your Token to a Server

Dev Nestio — Sat, 27 Jun 2026 17:53:20 +0000

Pasting a JWT into an online decoder is a surprisingly bad idea. The payload is just base64url — not encrypted. Whatever is in there (user ID, email, roles, scopes) is visible to whoever runs that server.

I built a JWT Decoder & Inspector that decodes entirely in your browser, with no network requests.

👉 https://jwt-decoder.pages.dev

What It Shows You

Paste any JWT and you get:

Header — algorithm (alg), token type, key ID
Payload — all claims, formatted as pretty-printed JSON
Signature — the raw base64url value (not verified — more on that below)

Timestamp claims (exp, iat, nbf) are converted from Unix seconds to human-readable local time. The expiration status is shown explicitly:

exp: 2026-07-01 09:00:00 (local)  ✅ Valid

exp: 2026-06-01 09:00:00 (local)  ⚠️ Expired

The base64url Trap

The first implementation detail that trips people up: JWT uses base64url, not standard base64.

The differences:

+ → -
/ → _
Trailing = padding is omitted

Run atob() directly on a base64url string and you'll get an exception or garbage. You need to convert first:

function decodeBase64Url(str) {
  let b64 = str.replace(/-/g, "+").replace(/_/g, "/");
  while (b64.length % 4) b64 += "=";
  const bin = atob(b64);
  const bytes = Uint8Array.from(bin, c => c.charCodeAt(0));
  return new TextDecoder("utf-8").decode(bytes);
}

The second trap: multibyte characters. atob() returns a binary string, not a JavaScript string. If the payload contains non-ASCII content (names in non-Latin scripts, emoji), you'll get mojibake unless you pipe the bytes through TextDecoder. This produces subtle, hard-to-reproduce bugs — works fine for most tokens, breaks on specific ones.

Timestamp Math

JWT timestamps are Unix seconds, not milliseconds. The Date constructor takes milliseconds. Off-by-1000x gives you a date in 1970:

const exp = payload.exp ? new Date(payload.exp * 1000) : null;
const isExpired = exp ? exp.getTime() < Date.now() : false;

Obvious in hindsight, but the bug appears constantly.

Why the Decoder Doesn't Verify Signatures

This was a deliberate design choice: no signature verification.

To verify a JWT signature you need either the secret (HS256) or the public key (RS256/ES256). Adding a "paste your secret here" form would undermine the whole point of the tool. You'd be putting your signing material into a browser text box, which is exactly the kind of thing this tool is trying to avoid.

The tool's job is decoding — reading what's inside the token. Verification belongs in your backend library. The UI makes this explicit with a notice: "Signature is not verified."

Keeping scope narrow makes the tool trustworthy.

No Framework, No Dependencies

JWTs have three parts separated by dots. Splitting on . and decoding each part doesn't need React. A single HTML file with vanilla JS is faster to load, has no CDN dependencies to audit, and works offline from browser cache.

Validated with 31/31 passing tests: base64url edge cases (with and without padding, containing - and _), multibyte payloads, expired vs. valid expiration detection, and malformed JWTs (missing parts, corrupted base64) that display errors instead of throwing exceptions.

Try It

Next time you're debugging auth and need to check what's actually in a token:

👉 JWT Decoder & Inspector — devnestio

All tools: https://devnestio.pages.dev

Works offline. Your token never leaves your browser.

I Built a Browser-Only Hash Generator (MD5, SHA-1, SHA-256, SHA-512 — No Server)

Dev Nestio — Sat, 27 Jun 2026 17:53:17 +0000

You need an SHA-256 of a string. You could open a terminal. Or you could paste it somewhere online — but then you're sending potentially sensitive data (a test password, an internal identifier) to a server you don't control.

I built a Hash Generator that computes MD5, SHA-1, SHA-256, SHA-384, and SHA-512 entirely in your browser. No network requests, works offline.

👉 https://hash-generator-745.pages.dev

Five Algorithms, One Paste

Paste your input and all five hashes appear simultaneously. Click any hash value to copy it.

MD5 — legacy checksums, file integrity verification
SHA-1 — older protocols, Git object IDs
SHA-256 — API signatures, file checksums, TLS certificates
SHA-384 — NIST recommended, TLS 1.3
SHA-512 — high-security contexts

Results update on every keystroke. No "submit" button.

Why This Matters for Sensitive Inputs

Hash generators have a privacy problem most people don't think about: the input is often sensitive.

You're checking a checksum? You're pasting the file contents or a candidate value. You're debugging an API signature? You're pasting the signing key material or payload. You're validating a password hash? You're pasting a test password.

Most online hash tools run on servers. That input travels over the network. With a client-side tool, the computation never leaves your browser — the server only delivers the HTML once.

The Technical Highlight: MD5 Is Missing From Web Crypto API

SHA-256, SHA-384, and SHA-512 are built into every modern browser via the Web Crypto API:

async function sha(algo, text) {
  const data = new TextEncoder().encode(text);
  const buf = await crypto.subtle.digest(algo, data); // "SHA-256" etc.
  return [...new Uint8Array(buf)]
    .map(b => b.toString(16).padStart(2, "0"))
    .join("");
}

Note the padStart(2, "0") — skip that and 0x0a becomes "a" instead of "0a", silently corrupting every hash that has a leading-zero byte.

MD5 is intentionally excluded from Web Crypto API because it's cryptographically broken. But MD5 checksums are still common in legacy systems, file downloads, and package verification. So MD5 required a manual implementation in plain JavaScript — bitwise operations, 4-round structure, little-endian byte order, all of it.

This creates an asymmetric architecture: SHA variants use a one-liner browser API; MD5 uses ~80 lines of hand-written JS. The MD5 implementation is validated against RFC 1321 test vectors:

""       → d41d8cd98f00b204e9800998ecf8427e
"abc"    → 900150983cd24fb0d6963f7d28e17f72
"message digest" → f96b697d7cb7938d525a2f31aaf161d0

All 42 test cases pass including multi-byte Unicode inputs.

No Frameworks, No Dependencies

A hash calculator has one input and five outputs. React's overhead — build tooling, bundle size, dependency updates — isn't justified here. A single HTML file with vanilla JS loads faster, has no supply chain attack surface, and works from browser cache after first visit.

Tool complexity:    low
Framework overhead: high
Decision:           vanilla JS wins

This is devnestio's rule across all tools: single HTML file, zero external dependencies.

What's Coming Next

File drag-and-drop for checksumming files directly (with chunked processing for large files)
HMAC support (keyed hashing)
Comparison mode — paste an expected hash and verify against it

Try It

For checksum verification, API debugging, or any time you need a quick hash without sending data to a server:

👉 Hash Generator — devnestio

All tools: https://devnestio.pages.dev

Fully offline after first load. All computation stays in your tab.

I Built a Bidirectional CSV ↔ JSON Converter With Zero Dependencies (RFC 4180 Compliant)

Dev Nestio — Sat, 27 Jun 2026 17:51:55 +0000

The use case comes up constantly: you have a spreadsheet export you need as JSON for a mock, or an API response you need in CSV to share with a non-engineer. Most tools handle the happy path fine — it's the edge cases that bite you.

I built a CSV ↔ JSON Converter that handles quoted fields, embedded commas, escaped quotes, and mixed delimiters correctly. All in the browser, no server.

👉 https://devnestio.pages.dev/csv-json-converter/

What's Wrong With `split(',')`?

If you've ever tried to parse CSV with a naive split, you know the answer: it breaks the moment a field contains a comma.

name,note
"Smith, John","He said ""hi"""

Split on commas and you get 4 fields instead of 2. The devnestio converter uses a state machine parser that handles this correctly per RFC 4180.

What It Does

CSV → JSON (Object Array)

Row 1 is treated as headers; each subsequent row becomes an object:

id,name,active
1,Alice,true
2,Bob,false

[
  { "id": 1, "name": "Alice", "active": true },
  { "id": 2, "name": "Bob", "active": false }
]

Type inference runs automatically: numeric strings become numbers, true/false become booleans.

JSON → CSV

Object arrays convert back to CSV. Keys from all objects are unioned into the header row, so rows with missing keys don't misalign columns:

[
  { "id": 1, "name": "Alice" },
  { "id": 2, "name": "Bob", "city": "Tokyo" }
]

id,name,city
1,Alice,
2,Bob,Tokyo

Multiple Delimiter Support

Toggle between comma, tab (TSV), and semicolon. Useful for:

Spreadsheet copy-paste (produces tab-separated output)
European CSV files (semicolon-separated because commas are decimal separators)

Smart Type Inference

CSV is all strings. Converting to JSON raises the question: do you turn "123" into 123 or leave it as "123"?

The rules this tool uses:

Matches ^-?\d+(\.\d+)?$ → number
true / false (case-insensitive) → boolean
Empty string → empty string "" (not null — preserves information)
Everything else → string
Leading zeros are preserved as strings ("007" stays "007")

That last rule matters. Zip codes and IDs that start with zero get silently corrupted if you aggressively cast to numbers.

The Parser: State Machine, Not Split

The core CSV parser tracks a single inQuotes flag and processes one character at a time:

function parseCSV(text, delimiter) {
  const rows = [];
  let field = '', row = [], inQuotes = false;
  for (let i = 0; i < text.length; i++) {
    const c = text[i];
    if (inQuotes) {
      if (c === '"' && text[i + 1] === '"') { field += '"'; i++; }
      else if (c === '"') { inQuotes = false; }
      else { field += c; }
    } else {
      if (c === '"') inQuotes = true;
      else if (c === delimiter) { row.push(field); field = ''; }
      else if (c === '\n') { row.push(field); rows.push(row); field = ''; row = []; }
      else if (c !== '\r') field += c;
    }
  }
  if (field !== '' || row.length) { row.push(field); rows.push(row); }
  return rows;
}

One flag handles commas, newlines, and escaped quotes correctly. Skimping on this is how you end up with a converter that "mostly works" until it hits real data.

Validated with 120/120 passing tests covering embedded commas, embedded newlines, escaped quotes, empty fields, mismatched keys, and all three delimiter modes.

No External Libraries

papaparse would make this a 10-line project. But devnestio's rule is single HTML file, zero external dependencies — so data you paste never touches a CDN script, and the tool works offline after first load.

Try It

For anyone who regularly shuffles data between spreadsheets and APIs:

👉 CSV ↔ JSON Converter — devnestio

All tools: https://devnestio.pages.dev

If you hit a CSV that breaks it, share it in the comments — real-world edge cases are the best test cases.

18 Browser-Only Developer Tools I Built With AI Agents

Dev Nestio — Wed, 17 Jun 2026 23:20:33 +0000

webdev #tools #productivity #javascript

A while back I had a question I couldn't shake: what if an AI agent could autonomously plan, build, and ship developer tools — not just assist a human doing it, but actually own the entire pipeline from concept to deployment?

That experiment became devnestio — an autonomous AI studio that mass-produces free, no-nonsense developer tools for the English-speaking dev community. We're now running 18 tools live on Cloudflare Pages, all built by Claude AI agents with minimal human intervention. Here's the honest story of how it works — and the full list of everything we've shipped.

What Is devnestio?

devnestio is a free developer toolsite factory powered by Claude AI agents. The goal is simple: build the kind of small, focused utility tools that developers reach for constantly — JWT decoders, regex testers, timestamp converters — and ship them fast, free, and without accounts, tracking, or paywalls.

Every tool runs as a single HTML file on Cloudflare Pages. No server, no backend, no build step. Vanilla JS, zero dependencies. It loads instantly, works offline, and costs nothing to run at scale.

The twist is that a human isn't writing most of this. Claude agents are.

The Agent Setup

devnestio uses two types of Claude sessions working in tandem: a Dispatch session and Code sessions.

Dispatch is the strategic brain. It runs as a persistent planning agent that identifies tool ideas worth building (based on developer search demand, tool simplicity, and gap analysis), writes detailed spec documents ("発注書" — purchase orders), prioritizes the backlog, and hands off specs to Code sessions. It also handles post-deployment tasks: logging metadata to Obsidian, updating the hub index, and tracking the overall portfolio.

Code sessions are ephemeral execution agents. Each one receives a spec from Dispatch, implements the tool as a single-file HTML/JS application, runs internal testing, and produces a deployable artifact. They operate independently and terminate once the tool is done.

The handoff looks roughly like this:

Dispatch → writes spec (tool name, features, UX requirements, edge cases)
         → spins up Code session with spec attached
         → Code session implements + self-tests
         → artifact saved to repo
         → Dispatch triggers Cloudflare Pages deploy
         → Dispatch logs result to Obsidian vault
         → loop repeats

Dispatch also maintains awareness of the full portfolio so it doesn't duplicate tools or suggest ideas that are too similar to existing ones.

This separation of concerns — strategy vs. execution — turned out to be the key insight. A single agent trying to plan and code simultaneously tends to cut corners on planning. Splitting the roles forces better specs, which produces better tools.

The Workflow: One Tool, Start to Finish

Let me walk through what building a single tool actually looks like in practice.

1. Ideation (Dispatch)
Dispatch evaluates tool candidates based on two criteria: is this something developers search for regularly, and can it be implemented cleanly in a single HTML file? A JWT decoder scores high on both — common need, self-contained logic, no server required. It gets added to the backlog.

2. Spec Writing (Dispatch)
Dispatch writes a detailed spec document covering: the tool's name and slug, core features, UX requirements (input/output layout, copy buttons, keyboard shortcuts), edge cases to handle (malformed tokens, expired JWTs), and non-goals (no signature verification against remote keys). The spec is precise enough that a Code session can execute without asking clarifying questions.

3. Implementation (Code session)
A Code session picks up the spec and builds the tool. Since everything is vanilla JS in a single HTML file, the agent doesn't need to manage dependencies, configure bundlers, or worry about deployment pipelines. It writes the HTML, styles it inline, implements the JS logic, and does a self-review pass checking the spec requirements against the implementation.

4. Testing
The Code session runs through the edge cases listed in the spec: empty input, invalid Base64, missing header/payload/signature segments, tokens with none algorithm. Any failures get fixed before the artifact is finalized. Each tool ships with a browser-based test suite (test.html) covering at minimum 30 test cases.

5. Deploy
The HTML file gets pushed to the repo and Cloudflare Pages auto-deploys it. Since there's no build step, the deploy takes about 30 seconds. The tool is live.

6. Logging (Dispatch)
Dispatch records the tool in the Obsidian vault: URL, deploy date, spec summary, and any known limitations. It also updates the hub index at devnestio.pages.dev so the new tool appears in the directory.

Total wall-clock time from "let's build a JWT decoder" to live URL: under an hour.

The bottleneck isn't writing code. It's writing a good spec. A vague spec produces a mediocre tool; a precise spec produces something genuinely useful.

The Tech Stack (Or Lack of One)

There's a certain pleasure in how little infrastructure this requires:

Cloudflare Pages — free tier, global CDN, automatic deploys from Git
Vanilla JS + single HTML files — no framework, no bundler, no node_modules
Obsidian — local Markdown vault for tracking the portfolio and specs
Claude API — powers both Dispatch and Code sessions

Total running cost at 18 tools: effectively $0/month on Cloudflare's free tier. The AI compute is the only real cost, and it's front-loaded during development rather than ongoing.

The single-HTML-file constraint turned out to be a feature, not a limitation. It forces simplicity. If a tool is getting too complex to fit cleanly in one file, that's a signal the scope is wrong.

The 18 Tools: Full List

Here's the complete portfolio, all live and free:

JWT Decoder & Inspector — decode and inspect JWT tokens entirely in the browser; detects algorithm, validates expiry, displays all claims in readable JSON. Your tokens never leave your machine.

Cron Expression Builder — build and test cron schedules visually with human-readable previews; supports standard 5-field and extended 6-field (with seconds) formats. Paste an existing cron expression to get it explained in plain English.

Regex Tester — live regex matching with real-time match highlighting and capture group display; flags (g, i, m, s, u) toggle instantly. Named and numbered capture groups both shown in the detail panel.

Base64 Encoder/Decoder — encode and decode Base64 with URL-safe variant support; handles file encoding for data URIs. Useful for inspecting JWT payloads and API responses.

Unix Timestamp Converter — convert between Unix timestamps and human-readable dates across timezones; auto-detects seconds vs. milliseconds and shows relative time ("3 hours ago").

URL Encoder/Decoder — encode/decode URLs and individual components with RFC compliance; shows the difference between encodeURI and encodeURIComponent behavior side by side.

CSS Color Converter — convert between HEX, RGB, HSL, and HSV with a live color preview; all four fields update simultaneously as you type in any one. Supports named CSS colors.

Hash Generator — generate MD5, SHA-1, SHA-256, SHA-384, and SHA-512 hashes in the browser using the Web Crypto API; supports file drag-and-drop for integrity verification.

Number Base Converter — convert between binary, octal, decimal, and hexadecimal with all four fields live-updating simultaneously; handles negative numbers with two's complement display.

String Case Converter — transform strings to camelCase, snake_case, PascalCase, kebab-case, SCREAMING_SNAKE_CASE, and more; handles edge cases like acronyms (XMLParser → xml-parser) and mixed input.

JSON Diff Tool — compare two JSON objects side-by-side with highlighted differences; additions, deletions, and modifications each get distinct color coding.

Lorem Ipsum Generator — generate placeholder text by words, sentences, or paragraphs; useful for UI prototyping and document templates.

UUID Generator — generate UUID v1 (time-based), v4 (cryptographically random), and v5 (namespace + name deterministic) in the browser using the Web Crypto API; batch generation up to 100 UUIDs, plus a validator.

Password Generator — generate secure passwords with configurable character sets (uppercase, lowercase, numbers, symbols) and strength indicator; everything runs locally, generated passwords never touch a server.

HTTP Status Codes Reference — searchable reference for all 61 HTTP status codes (1xx–5xx) with "when to use" guidance and real-world examples; covers the practical distinctions (401 vs 403, 301 vs 308, 400 vs 422) that are hard to find elsewhere.

JSON Formatter & Validator — format, minify, validate, and tree-view JSON in the browser; validation errors include line and column numbers, and the interactive tree view uses native <details>/<summary> elements — no framework.

SQL Formatter & Beautifier — format and beautify SQL queries with keyword casing control (UPPERCASE/lowercase/preserve) and minify mode; string literals are handled safely so keywords inside quotes are never transformed.

YAML Formatter & Validator — format, validate, and convert YAML ↔ JSON bidirectionally; error messages include line numbers; built with a hand-rolled Vanilla JS parser (zero npm packages) so your config files never leave the browser.

Browse everything at devnestio.pages.dev.

All 18 tools follow the same philosophy: one page, one purpose, loads in under a second, no login required.

Why Browser-Only?

The "no backend, no server" constraint isn't a technical limitation — it's a deliberate design choice that drives most of the product decisions.

Privacy: Developers regularly paste sensitive data into tools — JWT tokens with embedded credentials, SQL queries exposing schema details, YAML configs with API keys and hostnames, passwords being generated or verified. Routing any of this through a third-party server creates a trust problem that's hard to reason about. Browser-only eliminates it entirely.

Speed: No round-trip latency means interactions feel instantaneous. The regex tester highlights matches as you type. The color converter updates all four formats simultaneously as you type in any one. The JSON formatter validates in real time. This kind of responsiveness is only possible when compute is local.

Reliability: No backend means no backend failures, no rate limits, no maintenance windows. The tools work offline after first load. They work on flaky VPN connections. They work in air-gapped environments. There's nothing to go down.

Cost: Cloudflare Pages free tier has no bandwidth limits for static content. 18 tools, millions of potential requests, $0/month hosting cost. The economics only work because there's no compute to pay for.

What's Next

The immediate priority is getting accepted into EthicalAds — a developer-focused ad network that serves contextual, privacy-respecting ads. No trackers, no behavioral targeting, no third-party cookies. If approved, it becomes a sustainable revenue model that doesn't compromise the user experience — and aligns with the privacy-first philosophy of the tools themselves.

Beyond monetization, the roadmap is more tools. The backlog Dispatch maintains currently has 30+ candidates. Ideas in queue include a generic text diff viewer, a Markdown preview tool, a color palette generator, and a curl command builder.

The selection criteria stays the same: useful to working developers, implementable as a single HTML file, something you'd realistically reach for during a coding session.

Honest Reflections

A few things I didn't expect after building 18 tools this way:

The constraint is the product. Committing to "vanilla JS, single HTML, no server" sounds limiting. In practice it's the reason tools are fast, trustworthy, and cheap to operate. Users don't have to trust a backend they can't see.

Specs matter more than code. The Code sessions rarely produce bad implementations. They produce bad tools when the spec is vague. Investing Dispatch's time in precise specs — specifying edge cases, non-goals, and exact UX behavior upfront — pays off immediately in output quality.

Shipping beats polishing. A tool that's live and useful is infinitely more valuable than a tool that's 20% better but still in development. The iteration loop — ship, get feedback, improve — only works if you ship.

The hard problem isn't building. The hard problem is distribution. Getting 18 quality tools deployed is straightforward with this setup. Getting developers to find them and use them regularly is an entirely different challenge. Technical execution is the easy part.

Try It

If you're a developer who uses any of these kinds of tools, give them a spin at devnestio.pages.dev.

If something's broken, missing a feature, or you have a tool idea that should exist — drop it in the comments below. Dispatch is listening.

devnestio is an ongoing experiment in autonomous tool development. Building in public.

DEV Community: Dev Nestio

I Built a Visual Chmod Calculator in Pure Vanilla JS — Checkboxes ↔ Numeric ↔ Symbolic, 222 Tests

What It Does

The Core Logic

Numeric → Symbolic

Symbolic → Numeric

Why s vs S — and t vs T

Octal formatting

Binary representation

Keeping All Representations in Sync

Common Permissions Reference

Testing Without a Framework

Try It

I Built a Browser-Only HTML Entity Encoder/Decoder — Named, Decimal & Hex, 246 Tests

What It Does

The Core: Encoding in Three Modes

The Decode Regex

Building the Entity Maps

What's in the 253-entity Map

Testing: 246 Cases, No Framework

A Subtle Edge Case: Prototype Pollution in Decode

Try It

I Built a Color Picker & Palette Generator in Pure Vanilla JS — No Libraries, 187 Tests

What It Does

The Color Math

HEX ↔ RGB

RGB → HSL

RGB → HSV

Palette Generation

Hue normalization

The six palette types

Clipboard Copy

Testing: 187 Cases, No Framework

The Tricky Edge Case

Try It

I Built a QR Code Generator in Pure Vanilla JS — No Libraries, No Server, 202 Tests

Why No Libraries?

What the Tool Does

How QR Codes Actually Work

1. Data Encoding

2. Reed-Solomon Error Correction

3. Data Interleaving

4. Matrix Construction

5. Masking

6. Format Info Placement

Testing: 202 Cases, Node.js Built-in Only

The Hardest Bug

Try It

I Built a Browser-Only YAML Formatter & Validator (No Dependencies, Works Offline)

Why Yet Another YAML Tool?

What It Does

Format & Normalize Indentation

Validate with Line Numbers

Bidirectional YAML ↔ JSON Conversion

Minify

What YAML Structures Are Supported?

Why No External Libraries?

Try It

I Built a UUID Generator Using crypto.randomUUID() (Why Math.random() Is the Wrong Choice)

Why crypto.randomUUID() and Not Math.random()?

Fallback for Older Environments

What the Tool Includes

Validated Against Format Requirements

No Framework, No External Libraries

What's Next

Try It

I Built a Real-Time Regex Tester in the Browser (Capture Groups, Flags, No Libraries)

The Problem With Most Regex Tools

What It Does

Live Match Highlighting

Capture Group Inspector

Flag Toggles (With Instant Preview)

Match Count & Error Display

Real-World Examples

Under the Hood

Try It

I Built a JWT Decoder That Never Sends Your Token to a Server

What It Shows You

The base64url Trap

Timestamp Math

Why `s` vs `S` — and `t` vs `T`

Why `crypto.randomUUID()` and Not `Math.random()`?

What's Wrong With `split(',')`?