FlexUtil

A Developer's Guide to Data Formats and Identifiers

JSON, Base64, UUIDs, and passwords — the four everyday primitives that underpin almost every web app, plus the subtle mistakes that quietly break things in production.

By Sergei Selivanov Last updated

Almost every backend touches the same four primitives every day: JSON for structured data, Base64 for transport, UUIDs as primary keys, and passwords as the thing that eventually locks everything down. Each of them is deceptively simple and each of them has a well-defined failure mode that shows up in production logs. This guide collects the rules worth memorising and points to the FlexUtil tools that help when you're staring at a live bug.

JSON: the shape of the modern web

JSON (JavaScript Object Notation, RFC 8259) is the lingua franca of HTTP APIs, configuration files, and interchange formats. It has a small grammar — objects, arrays, strings, numbers, booleans, and null — and a few surprisingly common pitfalls.

Strict-JSON rules that trip people up

  • Double quotes only. {"name": "John"} is valid; {'name': 'John'} is not. Strings in JSON must use double quotes; keys must always be quoted.
  • No trailing commas. [1, 2, 3,] breaks most parsers. JavaScript's JSON.parse rejects them; YAML and JSON5 accept them, which is often the source of confusion.
  • No comments. Strict JSON has no // or /* */. If your input has them, you are looking at JSONC or JSON5, not JSON.
  • Numbers are doubles. A JSON number is parsed as a 64-bit float, which has only 53 bits of integer precision. If you're moving 64-bit IDs through JSON, transmit them as strings or they will silently round.
  • Duplicate keys. Technically allowed by the spec but discouraged; most parsers keep only the last value. Don't rely on a particular behaviour.

Minify for the wire, prettify for humans

A minified JSON response is 10–20% smaller than the same document pretty-printed. When gzipped on the wire, the difference shrinks to roughly 5% — often not worth the debugging cost. In checked-in config files, always commit the pretty version so diffs stay readable.

The JSON formatter runs entirely in your browser. Paste invalid JSON and it reports the exact line and column of the first syntax error; paste valid JSON and it reformats both ways.

When JSON is the wrong tool

  • Binary data. JSON has no binary type. Use Base64-encoded strings, or a binary format like Protobuf, Avro, or MessagePack.
  • Streaming. JSON's {...} structure requires the consumer to wait for the end before parsing. For log streams, use NDJSON (one JSON object per line).
  • Strict schemas. JSON is schema-less; use JSON Schema, OpenAPI, or Protobuf if your contract needs to be enforced at compile time.

Base64: getting bytes through text-only channels

Base64 (RFC 4648) maps three bytes to four printable ASCII characters. It exists because a lot of transport layers (email, HTTP headers, URLs, JSON) can only carry 7-bit text reliably. It is not encryption — Base64 is trivially reversible by anyone.

The two alphabets

  • Standard (A–Z a–z 0–9 + /) with = padding — used in email MIME, HTTP Basic auth, PEM-encoded certificates.
  • URL-safe (A–Z a–z 0–9 - _), often without padding — used in JSON Web Tokens, Webcrypto, query strings. The two alphabets are not interchangeable: a decoder for one will reject values from the other.

Common uses worth knowing

  • Data URIs — data:image/png;base64,iVBORw0KGgo... for inlining small images in CSS/HTML. Useful for icons, wasteful for anything above a few kilobytes (skips browser cache).
  • JSON Web Tokens — a JWT is three URL-safe Base64 segments joined by dots. Decoding the middle segment reveals the payload.
  • HTTP Basic auth — Authorization: Basic <base64-of-user:pass>. Not encrypted; always pair with TLS.
  • Binary-in-JSON — wrap byte fields as Base64 strings when the API format can't carry binary natively.

The size cost

Base64 inflates data by 4/3 (≈ 33%) plus a handful of padding bytes. For small blobs this is trivial; for a 10 MB image, it's 3.3 MB of extra bytes, which is why data URIs are bad for anything sizeable.

The Base64 encoder/decoder handles both alphabets, works on text or files, and runs entirely client-side — useful when you're debugging a token or config value that contains secrets.

UUIDs: the identifier question

A UUID (Universally Unique Identifier, RFC 9562) is a 128-bit value used to identify something without a central coordinator. Most modern stacks use one of two versions.

UUID v4: pure randomness

122 bits of cryptographic randomness plus 6 bits of version/variant markers. Collision probability is negligible (to have a 50% chance of collision you'd need to generate ~2.7×1018 values). Good for: anti-enumeration tokens, correlation IDs, anything where you don't want creation order to leak.

Downside: as a database primary key, v4 creates random writes across the B-tree index, causing page splits and cache misses. On high-throughput tables, this measurably hurts insert performance.

UUID v7: time-ordered

First 48 bits are a Unix millisecond timestamp; the rest is random. Consecutive v7 UUIDs sort in creation order, which means they land at the "hot" end of a B-tree index instead of scattering. This restores the index-friendliness of auto-incrementing integers without losing the decentralised-generation property of UUIDs.

PostgreSQL 18 added a native uuidv7() function in 2025; MySQL 9 supports it via a helper; Go, Rust, Python, Node.js, .NET, and Java all have maintained libraries. For any new database primary key today, v7 is the default answer. The FlexUtil UUID generator produces both v4 and v7 in bulk.

When not to use a UUID

  • URLs that a human will type or dictate. 32 hex characters plus dashes is miserable to transcribe. Use a shorter random slug or a URL-safe Base64 token.
  • Cases where 64 bits are enough. Most single-node systems are fine with a bigint primary key; UUIDs cost 16 bytes instead of 8 and are harder to index on some engines. Use them when you actually need decentralised generation.
  • Security tokens. UUIDs are for uniqueness, not unguessability alone. For session tokens, password reset links, and API keys, use wider random strings (128+ bits) with a dedicated library.

Passwords: entropy, not complexity theatre

Password strength is measured in bits of entropy: each bit doubles the number of guesses an attacker must make. For a random password, entropy is length × log2(pool size):

  • 12 chars, alphanumeric+symbols (94 symbols): 12 × 6.55 ≈ 78.6 bits
  • 16 chars, alphanumeric+symbols: 104.8 bits — effectively unbreakable for offline brute force
  • 20 chars, lowercase only (26 symbols): 94 bits — stronger than the 12-char mixed one, because length beats complexity

Practical rules

  • Generated & stored in a password manager: 16–20 chars from a full alphabet. No memorisation needed.
  • Manually typed (device login, manager master password): 6–7 random words from a large list (EFF's 7,776-word list produces ≈ 12.9 bits per word). Seven words ≈ 90 bits, and much easier to type correctly than a random string.
  • Never reuse. The single most effective defence against credential-stuffing attacks.
  • Enable multi-factor authentication, especially on email. Your email is the master key to every password reset.

The FlexUtil password generator uses the browser's Web Crypto API (crypto.getRandomValues) for cryptographically secure randomness, with rejection sampling to avoid modulo bias. Everything is generated in your tab and never transmitted.

What's replacing passwords

Passkeys (WebAuthn) — a public/private key pair stored in the device's secure enclave — eliminate both phishing and credential stuffing. They're widely supported in 2026 (Apple, Google, Microsoft, most major sites). When a service offers passkeys, use them. When it doesn't, generate a 16+-character password and MFA the account.

Quick reference

  • Debugging a JSON parse error → look for trailing commas and unescaped quotes; validator will show the exact position.
  • Decoding a JWT → it's three URL-safe Base64 segments; grab the middle one and decode. The Base64 decoder supports the URL-safe alphabet.
  • Picking a primary-key type → v7 if you'll sort by creation order, v4 if you won't. See UUID generator.
  • Generating a password → 16–20 chars from the full alphabet if a manager stores it; 6–7 random words if you'll type it. See generator.
  • Testing a regex against real input → the regex tester uses the same ECMAScript engine as your Node.js or browser code.

Related tools

All Guides