DEV Community: mi8bi

I built a site with 150+ browser-only dev tools (Astro + Vue 3 + TypeScript) — here's how it's put together

mi8bi — Mon, 20 Jul 2026 00:00:00 +0000

What this is

Torinoa Tools is a side project I've been building solo: 152 developer utilities — Base64 conversion, JSON formatting, a regex tester, subnet calculators, AES encrypt/decrypt, and more — all in one site, all running entirely client-side.

No server processing — input never leaves the browser
Bilingual (Japanese/English) via Astro Content Collections
Static site built with Astro + Vue 3 + TypeScript, also distributed as a Docker image

Instead of a feature tour, this post is about a few implementation details I think are worth sharing: a build-time architecture fix, a Web Crypto–only encryption tool, and a small VLSM subnetting algorithm.

The 755KB CSS chunk problem

Early on, all 143 tools shared a single dynamic route, pages/tools/[slug].astro, and a "switchboard" component (ToolWidget.astro) statically imported all 143 Vue widgets and branched on which one to render.

Because Vite extracts CSS from the entire dependency graph reachable from a route file, this meant one 755KB CSS bundle was shipped to all 286 pages (143 tools × 2 locales) — even though any single page only ever used one tool's worth of CSS.

The root cause wasn't how the files were split — it was that multiple tools shared one route file at all. The fix: generate a fully independent page file per tool (a separate module, from Vite's point of view) before every build.

// scripts/generate-tool-pages.mjs (excerpt)
function renderJaPage({ slug, component, importPath }) {
  const shellImport = shellImportPath(JA_OUT_DIR);
  const widgetImport = resolveWidgetImportPath(importPath, JA_OUT_DIR);
  return `---
import { getCollection } from "astro:content";
import ToolPageShell from "${shellImport}";
import ${component} from "${widgetImport}";

const entries = await getCollection(
  "tools",
  ({ id }) => id.split("/").pop()?.replace(/\\.md$/, "") === "${slug}",
);
const entry = entries[0];
---

<ToolPageShell entry={entry} locale="ja">
  <${component} locale="ja" client:load />
</ToolPageShell>
`;
}

src/data/tool-widgets.json holds the single source of truth — slug → { componentName, importPath } — and the script regenerates every .astro page from it in a predev / prebuild step. Generated files aren't committed; shared layout logic lives in ToolPageShell.astro so nothing is duplicated per-tool.

Result: CSS chunks went from a shared 755KB down to under 16KB per page. Adding a new tool is now just one entry in tool-widgets.json — page generation, CSS splitting, and i18n consistency checks all run automatically from there.

An AES tool built only on Web Crypto

No crypto library dependency — AES-GCM / AES-CBC encryption and decryption run entirely on the browser's native SubtleCrypto. Keys are derived from a passphrase using PBKDF2 (SHA-256, 100,000 iterations), and the salt, IV, and algorithm marker are packed together with the ciphertext into a single self-contained Base64 blob.

const PBKDF2_ITERATIONS = 100_000;

async function deriveKey(
  passphrase: string,
  salt: Uint8Array,
  algorithm: AesAlgorithm,
  keySize: AesKeySize,
): Promise<CryptoKey> {
  const enc = new TextEncoder();
  const baseKey = await crypto.subtle.importKey(
    "raw",
    enc.encode(passphrase),
    "PBKDF2",
    false,
    ["deriveKey"],
  );
  return crypto.subtle.deriveKey(
    { name: "PBKDF2", salt, iterations: PBKDF2_ITERATIONS, hash: "SHA-256" },
    baseKey,
    { name: algorithm, length: keySize },
    false,
    ["encrypt", "decrypt"],
  );
}

The final blob is [algorithm byte, keySize byte] + salt + IV + ciphertext, Base64-encoded, so decryption only ever needs the passphrase — nothing else has to be typed in again. AES-GCM's authentication tag doubles as tamper detection: if the passphrase is wrong or the data was altered, crypto.subtle.decrypt simply throws, with no extra integrity-checking code needed. This combined format is intentionally self-contained rather than OpenSSL-compatible — it's designed so the tool can decrypt what it encrypted, not to interoperate with external crypto tooling.

VLSM packing for the subnet calculator

One of the more niche tools does CIDR subnetting, including VLSM (Variable Length Subnet Masking). Given a list of required host counts, it sorts them descending, computes the needed host bits per subnet with ceilLog2(hosts + 2), and greedily packs each subnet aligned to its own boundary.

const sorted = [...reqs].sort((a, b) => b - a); // pack largest requirements first

for (const hosts of sorted) {
  const hostBits = ceilLog2(hosts + 2); // +2 for network and broadcast addresses
  const subnetSize = Math.pow(2, hostBits);
  const alignedNum = (Math.ceil(currentNum / subnetSize) * subnetSize) >>> 0;

  if (alignedNum + subnetSize - 1 > networkNum + parentTotal - 1) {
    // doesn't fit in the parent network — surface an error
  }
  // ... push subnet info, advance currentNum
}

If the requested subnets don't fit in the parent network, it fails explicitly rather than silently truncating — so you find out immediately whether your host-count list actually fits.

Auto-restoring input with localStorage (and a bug pattern worth knowing)

Almost every tool restores its input after you close the tab, via a small useLocalStorage composable:

export function useLocalStorage<T>(
  key: string,
  defaultValue: T,
  options: { debounceMs?: number; syncAcrossTabs?: boolean } = {},
): Ref<T> {
  const storageKey = `torinoa:${key}`;
  const state = ref<T>(defaultValue) as Ref<T>;

  if (typeof window !== "undefined") {
    const raw = window.localStorage.getItem(storageKey);
    if (raw !== null) state.value = JSON.parse(raw) as T;
  }
  // ... debounced writes back to localStorage
  return state;
}

Astro's SSG build has no window, so the guard just falls back to a plain in-memory ref during the build.

Sensitive tools — password generator, JWT tools, cookie parser, HMAC generator — deliberately skip this auto-restore behavior entirely.

One recurring bug worth naming: restore logic would be fully implemented in the script, but the corresponding <div class="restore-banner"> element was simply missing from the template — the feature worked, but was invisible to users. It happened often enough across widgets that "restore logic exists AND its UI element actually renders" is now a standing thing I check for, not just something I assume works because the code is there.

Enforcing bilingual parity

Japanese and English tool content live in separate Astro Content Collections (src/content/tools/ and src/content/tools-en/). A script, check-i18n-en-parity.mjs, runs before every build and checks:

Matching Markdown file counts between ja/en
Matching slug counts between tools.json and tools.ts
Matching category counts

Registering one new tool touches exactly four places — tools.json, tools.ts, and the ja/en Markdown files — and the parity script blocks the build if any of them are out of sync.

Self-hosting via Docker

Pre-built images are pushed to ghcr.io/mi8bi/torinoa-tools via GitHub Actions CI, tagged with latest, semver, and commit SHA. Since it's a fully static site, it's straightforward to self-host anywhere, including networks that can't reach the public internet.

Closing thoughts

The thing that's made maintaining 152 tools solo actually feasible is turning "remember to do X when adding a tool" into a script that enforces it — auto-generating pages instead of hand-writing switchboards, a parity checker instead of a mental checklist, catching "restore logic exists but its UI element doesn't" as a named pattern instead of a one-off bug. Scripts catching mistakes beats discipline, basically every time.

Site: https://tools.torinoa.com

Happy to answer questions about any of this in the comments.

Bulk-validating JSON test cases against a CSV schema with JSONPath (jsonpath-plus)

mi8bi — Sun, 19 Jul 2026 22:52:44 +0000

What this is

Of all the tools on Torinoa Tools, the one I personally use the most is the JSON Expected Value Validator. When working on APIs, I regularly need to check that a specific key in many different JSON test cases has the expected type or value. This tool lets you define validation rules with JSONPath in a CSV, then apply them across many JSON test cases at once.

What it does

Schema CSV (row-based): each row defines a JSONPath to check, the expected type, whether it's required, and a comparison mode
Test case JSON(s): upload or paste multiple JSON documents to validate
The tool cross-references both and shows a pass/fail grid — one row per rule, one column per test case

A schema CSV looks like this:

key,expected_type,required,compare_mode
$.user.id,number,true,
$.user.roles,array,true,unordered
$.user.email,string,false,

Evaluating JSONPath with jsonpath-plus

Path evaluation is handled by jsonpath-plus:

import { JSONPath } from "jsonpath-plus";

matches = JSONPath({ path: normalizePath(rule.key), json: data, wrap: true });

Passing wrap: true means zero, one, or many matches are all returned as an array, uniformly. That lets a path matching multiple elements ($.items[*].id) and a path matching exactly one ($.user.id) go through the same comparison logic downstream.

There's also light normalization so users can type user.id instead of $.user.id and still get a working path:

function normalizePath(rawKey: string): string {
  const key = rawKey.trim();
  if (key.startsWith("$")) return key;
  if (key.startsWith(".")) return "$" + key;
  return "$." + key;
}

Comparison modes

Rather than only supporting exact equality, there are four comparison modes:

function compareValues(
  expected: unknown,
  actualList: unknown[],
  mode: CompareMode,
): { pass: boolean; message: string } {
  if (mode === "length_only") {
    const expectedLen = typeof expected === "number" ? expected : Number(expected);
    const pass = actualList.every((a) => structuralLength(a) === expectedLen);
    return { pass, message: pass ? t("msgValuePass") : t("msgValueFail") };
  }
  if (mode === "contains") {
    const pass = actualList.every((a) => containsMatch(expected, a));
    return { pass, message: pass ? t("msgValuePass") : t("msgValueFail") };
  }
  const arrayMode: "exact" | "unordered" = mode === "exact" ? "exact" : "unordered";
  const pass = actualList.every((a) => deepEqual(expected, a, arrayMode));
  return { pass, message: pass ? t("msgValuePass") : t("msgValueFail") };
}

exact — full equality, array order included
unordered — arrays match as sets; order doesn't matter
contains — the expected value just needs to appear within the actual value (partial match)
length_only — only checks the length of an array or string, not its contents

When testing API responses, "the array's contents should match but order isn't guaranteed" comes up constantly, so unordered is the default comparison behavior. When a JSONPath matches multiple elements, the same comparison runs against every match, and every() requires all of them to pass for the rule to succeed.

The bug that took the longest to track down: CSV escaping

The hardest part of building this tool wasn't the JSONPath logic — it was CSV escaping. Schema JSONPaths sometimes contain filter expressions with embedded double quotes, e.g. $.items[?(@.type=="premium")]. Treated as a single CSV field, that needs proper RFC 4180 quoting, or the string silently corrupts on parse.

export function escapeCsvField(value: string, delim: string): string {
  if (
    value.includes(delim) ||
    value.includes('"') ||
    value.includes("\n") ||
    value.includes("\r")
  ) {
    return `"${value.replace(/"/g, '""')}"`;
  }
  return value;
}

A field only gets wrapped in quotes if it contains the delimiter, a double quote, or a newline — and any embedded double quotes get doubled up. This got pulled out into a shared utility (src/utils/csvParse.ts) used by every CSV-related widget on the site. Before that fix existed, sample data with a double-quoted JSONPath filter would silently corrupt the CSV on parse — the kind of bug that's easy to miss because nothing throws, the data just quietly comes out wrong.

Parsing lives in the same file:

export function parseRow(row: string, delim: string): string[] {
  const fields: string[] = [];
  let cur = "";
  let inQ = false;
  for (let i = 0; i < row.length; i++) {
    const ch = row[i];
    if (ch === '"') {
      if (inQ && row[i + 1] === '"') {
        cur += '"';
        i++;
      } else {
        inQ = !inQ;
      }
    } else if (ch === delim && !inQ) {
      fields.push(cur);
      cur = "";
    } else {
      cur += ch;
    }
  }
  fields.push(cur);
  return fields;
}

Delimiter detection is automatic too — it inspects the first line, ignoring anything inside quotes, and picks whichever of comma/tab/semicolon/pipe appears most — so pasting in CSV, TSV, or semicolon-separated data all just work without asking the user to specify a format up front.

Wrap-up

jsonpath-plus handles the actual path evaluation, but the real design work was elsewhere: how to treat single vs. multiple matches uniformly, how many comparison modes are actually worth supporting, and how strict to be about CSV escaping. That last one is easy to underestimate, but it directly affects whether the validation results you're looking at are actually trustworthy — worth building carefully as a shared utility rather than re-solving per widget.

Try it here: https://tools.torinoa.com/tools/json-expected-value-validator/

Implementing VLSM (Variable Length Subnet Masking) subnet packing

mi8bi — Sun, 19 Jul 2026 13:42:27 +0000

What this is

Torinoa Tools includes a subnet calculator that splits a CIDR block into subnets. Beyond simple "split into N equal subnets," it also supports VLSM (Variable Length Subnet Masking).

VLSM handles the case where each subnet needs a different number of hosts — say, HQ needs 100 hosts, Branch A needs 50, Branch B needs 25, and a DMZ needs 10 — and you want to allocate address space without wasting it. Here's how the packing algorithm is implemented.

What actually needs computing

For each subnet in a VLSM plan, you need:

The smallest prefix length (subnet mask) that can fit the requested host count
A starting address inside the parent network that doesn't overlap any other subnet

Part 1 is a straightforward formula. Part 2 requires processing requirements largest-first and packing them into the address space in order.

Computing the required host bits

In IPv4, usable hosts per subnet = total addresses in the subnet minus 2 (network address and broadcast address). So you need the smallest n (host bits) such that 2^n - 2 >= requested hosts.

const hostBits = ceilLog2(hosts + 2);
const subnetPrefix = 32 - hostBits;
const subnetSize = Math.pow(2, hostBits);

Passing hosts + 2 into ceilLog2 bakes in the "minus network and broadcast address" adjustment up front, rather than handling it separately later.

Pack largest requirements first (greedy)

The standard approach for VLSM address allocation is to place the largest subnets first. If you pack smallest-first, you end up with gaps when a later, larger subnet has to align to its own boundary — wasting address space that a different ordering wouldn't have wasted.

function calculateVlsm(networkNum: number, prefix: number, parentTotal: number) {
  const reqs = vlsmRequirements.value;

  // Sort descending for efficient packing
  const sorted = [...reqs].sort((a, b) => b - a);

  let currentNum = networkNum;
  const subnets: SubnetResult[] = [];

  for (const hosts of sorted) {
    const hostBits = ceilLog2(hosts + 2);
    const subnetPrefix = 32 - hostBits;
    const subnetSize = Math.pow(2, hostBits);

    // Align to subnet boundary
    const alignedNum = (Math.ceil(currentNum / subnetSize) * subnetSize) >>> 0;

    if (alignedNum + subnetSize - 1 > networkNum + parentTotal - 1) {
      // Doesn't fit in the parent network
      errors.value.value = t("errVlsmOverflow");
      results.value = [];
      return;
    }

    const subnetMask = maskFromPrefix(subnetPrefix);
    const broadcastNum = (alignedNum + subnetSize - 1) >>> 0;

    subnets.push({
      network: numToIp(alignedNum),
      mask: numToIp(subnetMask),
      broadcast: numToIp(broadcastNum),
      firstHost: numToIp(alignedNum + 1),
      lastHost: numToIp(broadcastNum - 1),
      usableHosts: subnetSize - 2,
      totalAddresses: subnetSize,
      prefix: subnetPrefix,
    });

    currentNum = alignedNum + subnetSize;
  }

  results.value = subnets;
}

Aligning to a subnet boundary

CIDR subnets can only start at an address that's a multiple of their own size (a /23, 512 addresses, can only start on an address divisible by 512). This line finds "the next valid boundary at or after currentNum":

const alignedNum = (Math.ceil(currentNum / subnetSize) * subnetSize) >>> 0;

Dividing currentNum (the address right after the previous subnet) by subnetSize, rounding up, then multiplying back by subnetSize gives the nearest aligned address that's >= currentNum. The >>> 0 coerces to an unsigned 32-bit integer — a common idiom when doing bitwise arithmetic on IPv4 addresses represented as numbers.

Overflowing the parent network is a hard error, not a silent truncation

if (alignedNum + subnetSize - 1 > networkNum + parentTotal - 1) {
  errors.value.value = t("errVlsmOverflow");
  results.value = [];
  return;
}

Boundary alignment introduces gaps, so even if the sum of requested hosts is less than or equal to the parent network's total address count, alignment overhead can still make the plan not actually fit. Rather than silently dropping subnets or truncating, this returns an explicit error — so you find out right away whether your requirements genuinely fit, instead of getting a plan that's quietly wrong.

Wrap-up

VLSM itself isn't a hard algorithm, but getting three things right — sort descending, align to boundaries, and fail loudly on overflow — is enough for a correct, simple implementation. A small but genuinely useful tool if you've ever hand-calculated a subnet plan on paper.

Try it here: https://tools.torinoa.com/tools/subnet-calculator/

Building an AES encrypt/decrypt tool with nothing but the Web Crypto API

mi8bi — Sun, 19 Jul 2026 13:41:03 +0000

What this is

Torinoa Tools is a solo side project — a collection of browser-only developer utilities. One of them is an AES Encrypt / Decrypt tool that does AES-GCM/AES-CBC encryption and decryption entirely in the browser.

No CryptoJS, no external crypto library — just the browser's native SubtleCrypto (Web Crypto API). Here's how it's built.

Why avoid a crypto library

Keeps the tool's shipped bundle small
SubtleCrypto is a native implementation — faster and more auditable than a pure-JS crypto library
Fewer dependencies, less to maintain

The tradeoff: SubtleCrypto is a low-level API. Deriving a key from a user-supplied passphrase, and managing salt/IV, is on you.

Deriving a key from a passphrase (PBKDF2)

Users type a passphrase, not a raw AES key, so the tool derives one with PBKDF2:

const PBKDF2_ITERATIONS = 100_000;

async function deriveKey(
  passphrase: string,
  salt: Uint8Array,
  algorithm: AesAlgorithm,
  keySize: AesKeySize,
): Promise<CryptoKey> {
  const enc = new TextEncoder();
  const baseKey = await crypto.subtle.importKey(
    "raw",
    enc.encode(passphrase),
    "PBKDF2",
    false,
    ["deriveKey"],
  );
  return crypto.subtle.deriveKey(
    { name: "PBKDF2", salt, iterations: PBKDF2_ITERATIONS, hash: "SHA-256" },
    baseKey,
    { name: algorithm, length: keySize },
    false,
    ["encrypt", "decrypt"],
  );
}

This is a two-step dance:

importKey("raw", ..., "PBKDF2", ...) treats the passphrase as PBKDF2 key material
deriveKey(...) actually derives the AES key from it

100,000 SHA-256 iterations. Since everything runs client-side and shouldn't freeze the UI, that number is a deliberate tradeoff between security and how long the browser blocks on the calculation.

A self-contained format: salt and IV travel with the ciphertext

Reusing the same key+IV pair for AES is dangerous, so a fresh salt and IV are generated on every encryption. Since decryption needs both, they're packed into one byte array together with the ciphertext and Base64-encoded:

export async function aesEncrypt(
  plaintext: string,
  passphrase: string,
  opts: AesOptions,
): Promise<AesEncryptResult> {
  const salt = crypto.getRandomValues(new Uint8Array(SALT_LENGTH));
  const iv = crypto.getRandomValues(new Uint8Array(ivLengthFor(opts.algorithm)));
  const key = await deriveKey(passphrase, salt, opts.algorithm, opts.keySize);

  const cipherBuffer = await crypto.subtle.encrypt(
    opts.algorithm === "AES-GCM"
      ? { name: "AES-GCM", iv }
      : { name: "AES-CBC", iv },
    key,
    new TextEncoder().encode(plaintext),
  );
  const ciphertext = new Uint8Array(cipherBuffer);

  const header = new Uint8Array([algoToByte(opts.algorithm), opts.keySize / 8]);
  const combined = new Uint8Array(
    HEADER_LENGTH + salt.length + iv.length + ciphertext.length,
  );
  combined.set(header, 0);
  combined.set(salt, HEADER_LENGTH);
  combined.set(iv, HEADER_LENGTH + salt.length);
  combined.set(ciphertext, HEADER_LENGTH + salt.length + iv.length);

  return { combined: uint8ToBase64(combined), /* ...hex breakdown for display */ };
}

The binary layout:

[algorithm byte] [keySize/8 byte] [salt (16 bytes)] [IV (12 or 16 bytes)] [ciphertext]

Encoding the algorithm and key size into the first two bytes means decryption can figure out AES-GCM vs. AES-CBC, and the 128/192/256-bit key size, straight from the ciphertext itself. So the person decrypting only ever needs to type the passphrase — no separate dropdown for algorithm or key size on the decrypt side. Small implementation detail, but it keeps the UI simpler.

Decryption gets tamper detection for free

export async function aesDecrypt(
  combinedBase64: string,
  passphrase: string,
): Promise<string> {
  const combined = base64ToUint8(combinedBase64.trim());
  const algorithm = byteToAlgo(combined[0]);
  const keySize = (combined[1] * 8) as AesKeySize;
  // ... slice out salt, iv, ciphertext

  const key = await deriveKey(passphrase, salt, algorithm, keySize);

  // Wrong passphrase or corrupted data both just throw here
  // (AES-GCM's auth tag verification doubles as tamper detection)
  const plainBuffer = await crypto.subtle.decrypt(
    algorithm === "AES-GCM" ? { name: "AES-GCM", iv } : { name: "AES-CBC", iv },
    key,
    ciphertext,
  );
  return new TextDecoder().decode(plainBuffer);
}

AES-GCM is an AEAD cipher — it appends an authentication tag to the ciphertext. That means a wrong passphrase, corrupted data, or tampering all just cause crypto.subtle.decrypt to throw, with no custom integrity-check code needed. This is probably the single best argument for reaching for SubtleCrypto directly instead of a higher-level wrapper library: the primitives already do the hard part.

One caveat: not designed for interop

This format is intentionally self-contained — built so the tool can decrypt what it encrypted — not designed to be binary-compatible with external tools like OpenSSL. Pasting output from openssl enc -aes-256-cbc into this tool won't decrypt (the header format differs). It's built for one specific use case: encrypt and decrypt entirely in the browser, nothing more.

Wrap-up

The Web Crypto API is low-level enough that you have to think through key derivation and your own wire format, but in exchange you get fine-grained control over exactly what's happening, with fewer dependencies to trust. Hopefully useful if you're building something similar.

Try it here: https://tools.torinoa.com/tools/aes-encrypt-decrypt/