DEV Community: Zhang Enquan

Cloudflare Just Shipped Post-Quantum at Internet Scale. Do You Need to Change Your Tools?

Zhang Enquan — Mon, 14 Sep 2026 13:19:23 +0000

On September 8, 2026, Cloudflare flipped the switch on post-quantum TLS origin handshakes across its edge. Two days later, on September 10, 1.1.1.1 enabled post-quantum DNSSEC powered by NIST's ML-DSA-44 algorithm. The numbers are not small: the TLS deployment alone now covers roughly 45 billion daily connections.

If you saw that headline and immediately opened your code editor to grep for md5 and sha256 — this post is for you. If you saw it and shrugged because you only use hashing for "checksumming" — this post is also for you.

If that's you — this is roughly what your terminal looks like right now:

$ rg -n "md5|sha256" src/ --color=always | head -20
src/main.c:1:    fprintf(stderr, "ERROR: Unsupported hash function: %s\n", hash_type);
src/CMakeLists.txt:21:    target_compile_options(${PROJECT_NAME} PRIVATE
                                                     -Werror=deprecated-declarations)
src/Rust/Cargo.toml:45:    version = "0.1.1"
src/Rust/Cargo.toml:46:    md5    = "0.10.0"
src/Rust/Cargo.toml:47:    sha256 = "0.9.0"
src/Rust/src/lib.rs:120:   let hash = md5::compute(data);
src/Rust/src/lib.rs:11:    let hash = sha2::Sha256::digest(data);
src/scripts/build.sh:15:    if ! command -v openssl   &> /dev/null; then
src/scripts/build.sh:15:    if ! command -v sha256sum &> /dev/null; then
src/scripts/build.sh:12:        echo "ERROR: Neither openssl nor sha256sum found!" >&2
src/scripts/util.sh:35:    md5sum    "$file" | awk '{print $1}'
src/scripts/util.sh:36:    sha256sum "$file" | awk '{print $1}'

(That's not a snippet from a real repo, but the panic it captures is.)

The short version: most of the tools you already use are fine. The panic comes from confusing hashes with encryption, and from using encryption when you actually needed a checksum.

Let's untangle that.

The panic that doesn't help

Here's what happened in a few Discord servers I read this week:

"Should I migrate from MD5 to SHA-256? Grover's algorithm makes SHA-256 only 128-bit secure anyway. Should I just go to SHA-3?"

"Should I rotate all my UUIDs to UUIDv7?"

"Is base64 still safe?"

These are reasonable questions if you don't know the answer. They are also three different categories of mistake.

MD5, SHA-1, and SHA-256 are hash functions. They produce a fixed-size fingerprint from any input. The reason they exist is not to keep secrets — it's to verify that data didn't change in transit. A 1GB ISO file you downloaded can be checksummed with any of them; the question is "did the bytes arrive intact", not "can someone read the bytes".

Base64 is an encoding, not encryption. It exists so that binary data can travel through channels (JSON, URL paths, email) that only support text. There is no key. There is no "secure" mode. Anyone who tells you base64 is "encrypted" is selling you snake oil.

UUID v4 is a random identifier, 122 bits of randomness. It's not a hash, not an encryption — it's a label. Whether quantum computers threaten it depends on whether you used a cryptographic random number generator (good) or Math.random() (you have bigger problems than Grover).

So when Cloudflare ships post-quantum TLS, here's what's actually happening at the protocol level:

The TLS handshake negotiates session keys using a key exchange algorithm that a quantum computer cannot efficiently break.
Everything inside that TLS tunnel — your HTTP traffic, your JSON, your base64-encoded blobs — is still protected by classical symmetric ciphers (AES-256-GCM, ChaCha20) and authenticated by classical hashes (SHA-256, SHA-384).
The risk model is "harvest now, decrypt later": an adversary records encrypted traffic today, waits for a cryptographically-relevant quantum computer (CRQC), then decrypts it. That's the threat post-quantum key exchange is closing.

Your MD5 checksum tool does not enter this picture.

What each tool is actually for

Since I built AI Subtools — a no-fluff browser-side toolbox — here's the honest guide. Same tool, different intent:

Tool	What it does	Threat model	Replace with PQC?
CRC32 Checksum Generator	Fast integrity check on small files / packets	Accidental corruption	No — error-detection, not security
MD5 Hash Generator	Legacy checksum, fingerprint for deduplication	Accidental corruption	No, for the same reason
SHA256 Hash Calculator	Strong fingerprint for file integrity / commit hashes	Accidental corruption	Optional — SHA-256 is fine for non-adversarial checks
Base64 Encoder/Decoder	Binary ↔ text transport	None — it's encoding	No — never was security
URL Encoder/Decoder	Make strings safe for URLs	None	No
UUID v4 Generator	Random 122-bit ID	Collision, predictability	No, if you use `crypto.getRandomValues`
Password Strength Check	Estimate entropy of a passphrase	Dictionary attack	The length matters, not the hash
Random Password Generator	High-entropy secrets	Predictability	No, if CSPRNG-backed
Encrypt/Decrypt (AES-256)	Symmetric encryption, browser-side	Adversary steals ciphertext	No — AES-256 is post-quantum-safe

The last row is the only one where a quantum computer would matter at all, and even then: Grover's algorithm gives a quadratic speedup, which means AES-256 effectively becomes AES-128 — still considered computationally infeasible to break. NIST standardized it for exactly that reason.

So when do you actually need post-quantum?

There are exactly three situations where PQC migration matters for the average developer:

You run a TLS server. Migrate your server library to support hybrid Kyber/X25519 key exchange (OpenSSL 3.5+, BoringSSL, rustls 0.23+). Cloudflare already did this for you if your users connect via their edge.
You sign software or firmware updates. Classic ECDSA signatures are quantum-broken. Migrate to ML-DSA-44 / Dilithium for new releases; consider re-signing historical binaries if your threat model includes harvest-now-decrypt-later.
You embed long-lived secrets in firmware or code signing certificates. Anything with a 10+ year shelf life needs a PQC plan now.

Everything else — your file checksums, your base64-encoded JSON payloads, your UUIDs, your SHA-256 commit hashes — is already fine.

A simple decision tree

When you reach for one of these tools, ask one question: am I protecting against bit-flips, or against an adversary?

Bit-flips only (corrupted download, broken pipe, accidental edit) → CRC32, MD5, SHA-256. Any of them. CRC32 is fastest; SHA-256 is most defensible.
Adversary who can read but not modify → AES-256 encryption. Done.
Adversary who can read and modify → authenticated encryption (AES-GCM) or HMAC over the ciphertext.
Adversary with a quantum computer who recorded your traffic years ago → PQC key exchange at the protocol layer (already handled by Cloudflare, AWS, GCP, Fastly, Akamai in 2026).

That's it. No framework. No vendor lock-in.

FAQ

Q: Is MD5 broken?
Yes, but not for checksumming. Collision attacks against MD5 mean you can craft two different files with the same MD5 — useful for forging signatures, useless for catching accidental corruption. Use MD5 for cache keys, deduplication, and legacy file verification. Don't use it for digital signatures — that hasn't been safe since 2008.

Q: Should I switch to SHA-3 for file integrity?
No reason to. SHA-256 is fine for non-adversarial integrity. The actual quantum risk lands on digital signatures and key exchange, not on file checksums.

Q: Is base64 encryption?
No. It is an encoding. There is no key. Anyone — including this page's CSS — can decode it. If someone tells you they "encrypted it with base64", they did not.

Q: Is UUID v4 quantum-safe?
UUID v4 is 122 bits from a CSPRNG. Brute-forcing 122 bits is computationally infeasible even with Grover's algorithm — you'd need ~2^61 operations, which is more atoms than in a kilogram of lead. As long as your UUID generator uses a cryptographic random source, you're fine.

Q: What about AES-256?
Post-quantum-safe by design. Grover halves effective key length to 128 bits. NIST confirmed AES-256 is acceptable for top-secret data through the post-quantum era.

Closing thought

Cloudflare's PQC deployment this week was an infrastructure milestone, not a consumer panic trigger. The right response is to make sure your TLS library supports hybrid post-quantum key exchange — not to throw out your hash functions.

If you're picking a tool for a one-off task today, pick the one that matches the threat model, not the trend.

— Built and maintained at aisubtools.xyz — 40+ free browser-side tools for developers and creators.

Open-sourcing my dev tools as plain HTML files (no npm, no build)

Zhang Enquan — Thu, 10 Sep 2026 07:48:49 +0000

```Last month I shipped three developer utilities — a Base64 encoder, a Unix
timestamp converter, and a CSS minifier. Each one runs100% in your browser.
No servers, no uploads, no analytics, no tracking.
\

Yesterday I open-sourced them on GitHub. This post is the story of why I
built them this way and why I open-sourced them at all.

The problem with "free online tools"

Most "free online tools" secretly upload your input to a server, process it
there, and hope nobody keeps a copy. That is a terrible default.

Try this experiment: paste 你好世界 🌍 into the most popular online Base64
encoder. About half of them will return å¥½ä¸ç•Œ — broken output that no
longer decodes back to what you typed. Why? Because most sites treat text as
Latin-1 by accident.

Even when they work correctly, you're trusting that the site:

won't log your input
won't sell it to a third party
won't get breached next year
won't disappear and take your workflow with it

Open source fixes all four.

What I shipped

I run aisubtools.xyz — a collection of free online
utilities where nothing ever leaves your browser. Yesterday I extracted
three of them into a standalone open-source repo:

🔗 github.com/enquannacc/aisubtools-browser-tools

Tool	What it does
Base64 encoder/decoder	Handles UTF-8 correctly via `TextEncoder` / `TextDecoder`. No mojibake.
Unix timestamp converter	Bidirectional conversion with local and UTC time, plus a live clock.
CSS minifier	Regex-based whitespace stripper with before/after size savings.

MIT licensed. No npm install. No build step. No dependencies. Open the file,
use it, close the tab. Done.

The architecture: one HTML file per tool

Every tool in the repo is a single self-contained HTML file. Here's the
pattern I used across all three:


html
<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>Base64 Encode / Decode — Browser Tool</title>
  <style>
    /* ~100 lines of CSS — nothing fancy, system fonts, CSS variables */
 </style>
</head>
<body>
  <h1>Base64 Encode / Decode</h1>
  <p>Runs 100% in your browser — nothing is uploaded anywhere.</p>
  <textarea id="input" placeholder="Type or paste here"></textarea>
  <button id="convert">Convert</button>
  <textarea id="output" readonly></textarea>
  <script>
    const input = document.getElementById('input');
    const output = document.getElementById('output');
    const convert = document.getElementById('convert');

    let mode = 'encode';

    function utf8ToBase64(str) {
      return btoa(String.fromCharCode(
        ...new TextEncoder().encode(str)
      ));
    }

    function base64ToUtf8(b64) {
      const bytes = Uint8Array.from(atob(b64), c => c.charCodeAt(0));
      return new TextDecoder().decode(bytes);
    }

    convert.addEventListener('click', () => {
      try {
        output.value = mode === 'encode'
          ? utf8ToBase64(input.value)
          : base64ToUtf8(input.value.trim());
      } catch (e) {
        output.value = 'Error: ' + e.message;
      }
    });
  </script>
</body>
</html>

Why %20 Keeps Appearing in Your URLs: A Practical Guide to URL Encoding

Zhang Enquan — Sun, 06 Sep 2026 14:19:43 +0000

You paste a URL into your browser, hit Enter, and suddenly it's full of %20, %3F, and %26. Or worse — your API call fails because a query parameter contains a space or an & you didn't encode.

URL encoding trips up everyone eventually. The good news: it's much simpler than it looks. This is a practical guide to reading percent-encoded URLs, knowing when encoding happens automatically, and fixing the bugs it causes.

Why URL encoding exists at all

A URL has to be plain ASCII — but the real world isn't. Spaces, emoji, Chinese characters, ampersands... all of them need to travel through a URL without breaking its structure.

The solution: any character that isn't URL-safe gets replaced with a % followed by its hexadecimal byte value.

A space becomes %20 (hex 20 = 32 = space in ASCII)
& becomes %26
? becomes %3F

The ? and & are the interesting ones — because those characters do have a special job in URLs. That's the key to understanding the whole system.

The two categories you must not confuse

Every character in a URL falls into one of two buckets:

1. Reserved characters — they are part of the URL's structure:

: / ? # [ ] @ ! $ & ' ( ) * + , ; =

These have meaning: ? starts the query string, & separates parameters, # starts the fragment. If your data contains one of these characters, it must be encoded — otherwise the URL's structure gets corrupted.

2. Unsafe / non-ASCII characters — spaces, control characters, non-Latin text, emoji. They must also be encoded because URLs are transmitted as ASCII.

Everything else (letters, digits, -, _, ., ~) passes through untouched.

That's the entire mental model. When you see %26 in a URL, it doesn't mean "the website hates you" — it means the original data contained a literal & that had to be protected so it wouldn't be mistaken for a parameter separator.

The cheat sheet you'll actually use

Encoded	Character	Where you'll meet it
`%20`	space	Search queries, file names
`%2F`	`/`	Paths inside query params
`%3F`	`?`	A literal `?` in data
`%26`	`&`	Values containing `&`
`%3D`	`=`	Values containing `=`
`%25`	`%`	The classic double-encode bug
`%2B`	`+`	Legacy form encoding of spaces

About %25: this is my favorite interview question. If you see %2520 in a URL, the original data was %20 — someone encoded an already encoded string. The % became %25, leaving 20 intact. Double-encoding bugs almost always trace back to a URL being encoded twice by two different layers (your code + a library).

When encoding happens automatically (and when it doesn't)

This is where bugs sneak in. The browser encodes some things for you, but not everything, and not everywhere.

The browser address bar is forgiving. Type https://example.com/search?q=hello world and the browser will quietly encode the space for you. This hides bugs during manual testing that blow up when the same URL is requested programmatically.

fetch() and <a href> are NOT forgiving in the same way. Spaces and non-ASCII characters in a query string can produce malformed requests or, worse, silently work in one browser and fail in another.

Form submissions (GET forms) encode spaces as +. That's why hello+world and hello%20world can both mean "hello world", depending on which layer produced them. This is also why decoding a form-encoded string with the wrong decoder gives you literal + signs scattered through your data.

The JavaScript functions, once and for all

In JavaScript you have four tools, and picking the wrong one is a rite of passage:

// encodeURIComponent — for a VALUE going into a query string
encodeURIComponent("fish & chips? yes")
// "fish%20%26%20chips%3F%20yes"
// ✅ Encodes & and ? — the structure is protected

// encodeURI — for a WHOLE URL that's already assembled
encodeURI("https://example.com/search?q=hello world")
// "https://example.com/search?q=hello%20world"
// ✅ Leaves :// and ? alone, encodes the space

// decodeURIComponent / decodeURI — the reversals
decodeURIComponent("fish%20%26%20chips")
// "fish & chips"

The rule of thumb:

Encoding one value (about to insert it into a query string)? → encodeURIComponent
Encoding a complete URL that's already well-formed except for stray spaces/unicode? → encodeURI

The mistake I see most often: using encodeURI on a value. It leaves & and ? untouched, so fish & chips slips into the URL as-is and silently truncates your query string at the &.

// ❌ Broken: value contains & and ?
"https://example.com/q?" + encodeURI("fish & chips?")

// ✅ Correct
"https://example.com/q?" + encodeURIComponent("fish & chips?")

Three real bugs you'll eventually meet

1. The truncated query string. A search for Tom & Jerry becomes ?q=Tom and everything after & becomes a new (empty) parameter. The page loads, the search just returns wrong results. Maddening until you look at the Network tab.

2. The double-encoded redirect. You pass a ?next= parameter containing a full URL. Some middleware encodes it again. The redirect target now contains %253A instead of %3A. The fix is to decode exactly once at each layer, and to be disciplined about which layer owns encoding.

3. The emoji that kills your sitemap. Non-ASCII characters in URLs are legal (via encoding), but if your CMS or export script writes raw UTF-8 into an XML sitemap without encoding, Google may start complaining. Always encode before writing URLs into structured files.

When you just need to check one string quickly

For debugging, I keep a browser-side URL encoder/decoder bookmarked — paste the string, see it encoded and decoded side by side, copy whichever form you need. It runs client-side, so tokens and internal URLs never leave the browser. Pair it with console.log and the Network tab and you can diagnose 95% of encoding bugs in a minute.

The 30-second summary

%XX is just a character's hex byte value, prefixed with %
Reserved characters (& ? = / #) must be encoded when they're data, not structure
The address bar hides encoding bugs; test with fetch or curl
encodeURIComponent for values, encodeURI for whole URLs
%25 appearing where %20 should be means something double-encoded

URL encoding stops being scary the moment you stop reading %3F as noise and start reading it as "that's a literal question mark in the data". Once that clicks, every encoded URL you see becomes just... a string with a hat on.

Questions or war stories about encoding bugs?

I Built 35+ Browser-Side Tools Because I Was Tired of Uploading My Data to Random Servers

Zhang Enquan — Wed, 02 Sep 2026 14:50:11 +0000

Every time I needed to format a JSON payload or compress an image, I found myself on some random tool site with three problems:

My data went to their server. Paste a password or an API token into a "hash generator" and you're just trusting that site not to log it.
Ads everywhere. The tool was buried under banners, and half the buttons were ad-click traps.
Sign-up walls. Want to download your converted file? Create an account first.

So I built AI SubTools — a collection of 35+ free tools where everything runs client-side in JavaScript. No uploads. No accounts. No ads.

Why client-side matters

It's not just a privacy stance. When the tool runs in your browser:

It's instant. No round-trip to a server, no queue. Image compression happens as fast as your CPU allows.
It works offline once the page is loaded.
Your data never leaves your device. For tools that touch passwords, tokens, or checksums, this should be the default, not a feature.

Some of the more interesting tools

Cron expression generator & tester — with plain-English explanations of what your expression actually does
PNG background remover — runs entirely in-browser, no upload
Robots.txt + XML sitemap generator — for the SEO-minded
EAN/UPC barcode creator — for e-commerce sellers
JSON formatter & validator, Base64 encoder/decoder, MD5/SHA-256 generators — the daily-driver classics

The technical trade-offs

The hardest parts were making image compression and background removal perform well without WASM. Canvas-based processing is fast enough for most images, but there's a real art to avoiding UI freezes on large files — chunked processing and careful memory management matter more than raw algorithm speed.

What's next

The site is a side project that grew out of my own daily frustration. New tools are added regularly, and I'm currently prioritizing:

More file-format converters
Better mobile experience for the image tools

What tools would you want added? I'd genuinely love to hear what's missing from your daily workflow — the best suggestions will get built.

P.S. Everything is free, forever. No premium tier hiding the useful stuff.