DEV Community: Pablo Infante

SHA-256 is not encryption — and that's the whole point

Pablo Infante — Tue, 03 Nov 2026 22:16:54 +0000

The single most common mix-up I see in code reviews: treating a hash like encryption. They are different tools for different jobs, and the difference is the reason hashing is useful at all.

The one distinction that matters

Encryption is two-way: with the key, ciphertext → plaintext. It's for keeping something secret that you later need back.
Hashing is one-way: input → fixed-size digest, and there is no "un-hash." SHA-256 always returns 256 bits (64 hex chars), whether you feed it one byte or a gigabyte. You cannot recover the input from the digest — not "it's hard," it's not a reversible operation.

If you ever read that a hash "can be decrypted," that text is wrong. What attackers do instead is guess-and-check: hash candidate inputs and compare digests (that's what a rainbow table or a password cracker is). That's why hashing a password needs salt + a slow KDF (bcrypt/argon2), not raw SHA-256.

The properties that make it useful

Deterministic: same input → same digest, every time. That's what lets you verify.
Avalanche effect: change one bit of input and ~half the output bits flip. hello and hellp produce completely unrelated digests.
Fixed length: 256 bits regardless of input size.
Collision-resistant: finding two inputs with the same SHA-256 is computationally infeasible (unlike SHA-1, which is broken for collisions — migrate off it).

Where you actually use it

File integrity: publish a download's SHA-256; a user re-hashes the file and compares. Match = not tampered/corrupted.
Change detection / caching: hash content to make an ETag or a cache key.
Deduplication: identical content → identical digest.
Commit/version identity: content-addressed storage (Git is the famous example).

Not for: storing passwords with raw SHA-256 (too fast — use argon2/bcrypt), and never as a stand-in for encryption.

Check a digest quickly

When I just need to verify a string's hash or compare against a published checksum, Toolonium's hash generator does it in the browser — type or paste, get the SHA-256 (and other algorithms), nothing uploaded. Good for the "does this checksum match?" moment without dropping into a shell.

Takeaway

Reach for a hash when you need to verify or fingerprint, for encryption when you need to get the data back. They're not interchangeable, and "decrypt a hash" isn't a thing. Need a quick digest? Generate one here.

Still seeing raw-SHA-256 password storage in the wild? Share the worst one you've had to fix.

Password entropy, explained with the one number that matters

Pablo Infante — Tue, 03 Nov 2026 22:11:13 +0000

"Use a strong password" is useless advice without a definition of strong. The definition that actually holds up is entropy — how many bits of randomness the password has — and once you see the math, most "complex-looking" passwords turn out weak.

The formula

Entropy in bits is: bits = length × log2(poolSize)

poolSize is how many characters each position could have been:

lowercase only → 26 → ~4.7 bits/char
lower + upper → 52 → ~5.7 bits/char
lower + upper + digits → 62 → ~5.95 bits/char
+ symbols → ~95 → ~6.55 bits/char

So a 16-character password using all four classes is about 16 × 6.55 ≈ 105 bits in theory. A rough rule of thumb: < 50 bits is weak, 70–100 is solid, 100+ is strong for anything that could be attacked offline.

The punchline developers underestimate: length beats symbol-soup. Tr0ub4dour&3 (clever substitutions, 12 chars) has less entropy than a longer passphrase, because entropy scales linearly with length but only logarithmically with pool size. Add characters, not cleverness.

Why "human-chosen" ruins the math

The formula assumes each character is independently random. A human picking P@ssw0rd2024! doesn't get 13×6.55 bits — attackers' wordlists and mangling rules know that pattern, so the effective entropy collapses. The entropy number is only honest if the generator is actually random.

Generate one and see the number

Toolonium's password generator does exactly this and shows you the entropy as you tune it:

Length 8–64 (slider), default 16.
Toggle uppercase, lowercase, digits, symbols.
"No ambiguous characters" option to drop l/1/I/O/0 — useful when the password will be read aloud or typed from a screen.
It reports estimated entropy in bits and a strength label, so you're choosing with a number, not a vibe.

It runs entirely in the browser — the generated password is never sent anywhere, which is the only acceptable design for a tool whose whole job is producing a secret. (As always: for app-level generation use your platform's CSPRNG, e.g. crypto.getRandomValues; this is for the quick human-facing case — a new DB user, a seed, a one-off account.)

Takeaway

Stop eyeballing passwords. Pick a target of ~100 bits, get there with length first, and use a generator that's random and local so the entropy estimate is real. Try it here.

What entropy floor does your team enforce for service accounts? Curious where people draw the line.

Why I reach for a UUID v4 instead of an auto-increment ID

Pablo Infante — Tue, 03 Nov 2026 22:10:06 +0000

Auto-increment primary keys are fine until they aren't. The moment you have two services writing to the same logical dataset, a sharded table, an offline client that creates rows before it syncs, or a public URL you'd rather not have /orders/1, /orders/2 leaking your volume — the sequential integer starts to hurt.

That's the case for UUID v4.

What a v4 actually is

A UUID v4 is 128 bits, of which 122 are random (the rest are fixed version/variant bits). You get a value like:

f47ac10b-58cc-4372-a567-0e02b2c3d479

The useful property: you can generate one anywhere — on the client, in a worker, in three services at once — without coordinating with a central sequence, and the chance of a collision is negligible for any realistic volume. No round-trip to the database to ask "what's the next number?"

Where it earns its keep

Client-generated IDs: a mobile app can create a record offline, assign the UUID itself, and sync later with no renumbering.
Distributed writes: merge data from several sources without PK clashes.
Opaque public identifiers: /invoice/f47ac10b-… doesn't reveal how many invoices exist, unlike /invoice/4471.
Idempotency keys: send one with a request so a retry doesn't double-charge.

The honest trade-offs

I'm not going to pretend UUIDs are free:

They're bigger (16 bytes vs 4–8 for an int), which matters at index scale.
Random v4s scatter across a B-tree index, hurting insert locality — if that's your bottleneck, look at UUID v7 (time-ordered) or keep ints internally and expose UUIDs externally.
They're not secrets — unguessable isn't the same as authenticated. Don't use a UUID as a bearer token.

Grabbing one quickly

When I just need a handful for seed data, a config, or a test fixture, I use Toolonium's UUID generator — it produces v4 UUIDs in the browser, nothing sent to a server, no install. For bulk generation at runtime you'd obviously use your language's native library (crypto.randomUUID() in modern JS, uuid in Python, etc.), but for a quick one-off it saves opening a REPL.

Takeaway

Reach for UUID v4 when IDs must be created without central coordination or must not leak counts. Know the index cost, and consider v7 if insert ordering matters. Need one right now? Generate it here.

Teams that went UUID-only on primary keys: did the index trade-off ever bite you in production?

A no-upload JSON formatter that runs entirely in your browser

Pablo Infante — Tue, 03 Nov 2026 22:04:20 +0000

Every developer hits the same 30-second problem a dozen times a day: an API returns a wall of minified JSON, and you need to read it. You paste it somewhere, prettify it, maybe sort the keys, and move on.

The catch with "somewhere": a lot of online JSON formatters POST your payload to a server. When that payload is a production response with tokens, PII, or internal IDs, that's a quiet data-handling problem nobody signed off on.

The small rule I follow now

If a tool only transforms text, it has no business sending that text anywhere. Formatting JSON is pure string work — indent, parse, re-serialize. It can all happen on the client.

So when I need a quick format I use a client-side one: Toolonium's JSON formatter. The parsing and pretty-printing run in your browser; nothing is uploaded. No account, no paste-into-a-logged-server.

What it actually does

Indent control: 2 spaces, 4 spaces, tab, or minify (min) to go the other way and compact a blob.
Sort keys: alphabetize object keys — handy when you're diffing two responses that return fields in different orders.
Quick stats: it reports the size in bytes, the key count, and the nesting depth. Depth is the sleeper feature: a surprise depth of 7 usually means your "flat config" grew a structure you didn't intend.

A tiny example of the kind of input it's built for:

{"project":"Toolonium","tools":["calculate","convert","create"],"free":true}

Formatted at 2-space indent that becomes readable in one click, and it'll tell you it's ~92 bytes with 3 top-level keys.

When to reach for it vs your editor

Your editor's formatter is great inside a file. A browser tool wins for the throwaway case: a response pasted from curl, a log line, a webhook body you're debugging in a meeting. No file, no project, no extension — just read it and close the tab.

And because it's client-side, it's safe to paste the ugly real-world payload, not a sanitized toy one.

Takeaway

Prefer formatters that transform locally. For JSON specifically, there's no reason the text should leave your machine. If you want a zero-upload one, try it here — it's free and there's nothing to install.

What's your rule for pasting production JSON into online tools? Curious how others handle the "is this thing uploading my payload" question.