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).

Algorithm details: the entropy and randomness primitives

The password and UUID generators are the only tools in this cluster that depend on cryptographically-strong randomness; their correctness rests on two browser primitives.

Unbiased character selection (rejection sampling)

Given a charset of size K and a 32-bit unsigned random draw r, the naiver % K is biased toward smaller indices unlessK divides 2³². We compute threshold = 2³² − (2³² mod K), draw, and reject any r ≥ threshold. Expected number of draws per character: < 1.05 for anyK ≤ 2³²/16. The output is uniformly distributed over the charset.

Entropy accounting

Password entropy is length × log₂(K)bits. Our strength bands follow NIST SP 800-63B’s guidance:

UUID v7 layout (RFC 9562)

bits[0..47]   = unix_ms (48 bits)
bits[48..51]  = version = 0111 (4 bits)
bits[52..61]  = random or sub-ms counter (10 bits)
bits[62..63]  = variant = 10 (2 bits)
bits[64..127] = random (64 bits)
total random: 74 bits — collision-resistant in practice

Sources & references

Every tool in the cluster maps to a primary spec: Base64 to RFC 4648, JWT to RFC 7519, hashes to FIPS PUB 180-4, UUIDs to RFC 9562, password entropy to NIST SP 800-63B. The Web Crypto API itself is a W3C recommendation. See the Sources block below for the canonical URLs.

Assumptions & limitations

• Browser-only execution. Tools assume a modern browser with Web Crypto. Old or hardened environments (some kiosk locks, server-side Node-without-shims) will fall back to a JS implementation and lose cryptographic strength.
• No signature verification.JWT decoding inspects but doesn’t verify. Don’t use this tool as part of an authn pipeline.
• No MD5. Cryptographically broken for authenticated use; intentionally omitted even for checksumming. Use SHA-256 with a small performance tradeoff.
• No streaming for large inputs.The hash and Base64 tools load the full input into memory. Inputs >100 MB will pause the tab while encoding.
• No payload telemetry.We don’t log, store, or transmit anything pasted into these tools. The trade-off: we also can’t debug why a specific input mis-renders without the user reproducing it.
• UUID v7 timestamps are millisecond-precise. Generating >1000 UUIDs in the same millisecond relies on the 10-bit sub-ms randomness for ordering uniqueness.
• Password strength is a heuristic.Real attack difficulty depends on the attacker’s known patterns (dictionary, leaked-password sets), not just entropy.

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.