Code tools methodology

The Code clusterships ten utilities, all of which run entirely in the browser and none of which send their payload anywhere. This page documents what each tool actually does — the RFCs they conform to, the primitives they use, and what they deliberately don’t do.

Base64 (RFC 4648)

Standard alphabet: A-Z a-z 0-9 + /, padded with = to multiples of 4. URL-safe variant (base64url) replaces + with - and / with _, drops padding.

Implementation: JavaScript’s native btoa / atob handle the encoding, but they only support Latin-1 strings (each byte is one character). For UTF-8 we first encode the string with TextEncoder, then run btoa on the resulting byte array. This is the only way to safely Base64 arbitrary Unicode text in the browser without dependencies.

JWT decoder (inspection only, no verification)

JWTs (RFC 7519) are three base64url-encoded segments separated by dots: header.payload.signature. Our decoder splits, base64url-decodes header and payload, parses them as JSON, and displays the result. We do not verify the signature.

Signature verification requires the signing key — typically an HMAC secret or an RSA/ECDSA public key — which has to come from the issuer. A browser-only tool can’t meaningfully verify a JWT issued by a third party, so we don’t pretend to. Use the decoder for inspection; use your application’s server-side stack for actual verification.

Case converter

Translates between camelCase, snake_case, kebab-case, PascalCase, CONSTANT_CASE, Title Case, Sentence case, and lower / UPPER. The algorithm splits the input into “words” using a regex that matches case transitions, hyphens, underscores, and spaces, then reassembles in the target convention.

Edge case: numbers in identifiers. Our convention is to keep number-letter boundaries as word boundaries (so parseInt32 splits into parse, int, 32) but not to split letter-number boundaries within obviously-identifier-like sequences (so md5 stays a single word, not md_5).

Hash generator

SHA-1, SHA-256, SHA-384, SHA-512 via the Web Crypto API (crypto.subtle.digest), which is a thin wrapper over the OS’s native implementation. We deliberately don’t ship MD5 — the browser doesn’t provide it natively (because it’s cryptographically broken), and we’d rather not pull in a 2 KB shim to support a hash function nobody should use for anything security-relevant.

Output is lowercase hexadecimal. All operations are synchronous from the user’s perspective despite the Web Crypto API being async — the latency on modern devices is sub-millisecond for inputs under a megabyte.

UUID generator

Two variants:

• v4 (random): crypto.randomUUID() when available, falling back to a manual crypto.getRandomValues-driven generator. 122 bits of entropy.
• v7 (timestamp + random): 48-bit Unix timestamp ms + 74 bits of random. Sortable by generation time, which makes v7 the preferred choice for database primary keys.

Password generator

Uses crypto.getRandomValues with rejection sampling against the largest multiple of the charset size that fits in a uint32. This eliminates modulo bias — the naive random32 % charsetSizeapproach is biased when charsetSize doesn’t divide 2³² evenly, which is every realistic charset.

Entropy is computed as length × log₂(charset) bits and displayed live. The strength label maps entropy to five bands (very weak / weak / fair / strong / very strong) with thresholds matching common security guidance (NIST SP 800-63B recommends ≥ 80 bits for high-stakes use).

What we don’t do

• Encrypt or decrypt content. The Web Crypto API supports it; we don’t expose a UI because misusing crypto APIs is a footgun.
• Verify JWTs. See above.
• Pretty-print structurally — we preserve the user’s formatting where possible. For full pretty-printing use a dedicated formatter.
• Log payloads. Nothing the user pastes leaves the browser, ever.