DEV Community: Max

Check If a Password Was Breached Without Sending It (HIBP k-Anonymity)

Max — Tue, 07 Jul 2026 17:01:51 +0000

A junior dev on my team once wanted to add a "check if your password was breached" feature to our signup form. His first instinct: POST the plaintext password to Have I Been Pwned and warn the user if it came back dirty.

I stopped him before the PR got anywhere. Sending a user's raw password to a third party to prove it isn't compromised is the kind of irony that ends up in a postmortem.

The good news is that HIBP solved this exact problem years ago with a technique called k-anonymity, and it's genuinely clever. You can check any password against 900+ million breached credentials without ever sending the password, its full hash, or anything that identifies it. Let me walk through how it works, show the actual bytes on the wire, and explain why this is one of the few "phone home" security checks I trust in a browser.

The problem with a naive breach check

The obvious design is: hash the password, send the hash, get back yes/no. But a SHA-1 hash of a password isn't anonymous. SHA-1 is fast and unsalted here, and breach corpuses are massive. If you send the full hash 5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8, the server — or anyone sniffing the request — can reverse it in microseconds against a rainbow table. That hash is literally the word password. You've leaked the credential.

You need a way to ask "is this password in your list?" where the server learns nothing useful about which password you asked about. That's what k-anonymity buys you.

How the range API actually works

The trick is to send only the first 5 characters of the SHA-1 hash. Here's the full flow for the password password:

SHA-1("password") = 5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8
                    └─┬─┘└──────────────┬──────────────────┘
                   prefix (5)        suffix (35)

GET https://api.pwnedpasswords.com/range/5BAA6

You send 5BAA6. The server responds with every breached-hash suffix that shares that prefix — the tail 35 hex characters plus a breach count, one per line:

003D68EB55068C33ACE09247EE4C639306B:29
00658BFD1E05761042698D19D32CD9F1A8F:15
...
1E4C9B93F3F0682250B6CF8331B7EE68FD8:52372427
...

That last line is the one you care about. Your browser — not the server — scans the response for your suffix 1E4C9B93F3F0682250B6CF8331B7EE68FD8, finds it, and reads the count: 52,372,427. The word "password" has appeared in 52 million breached records.

The server never saw which suffix you were looking for. It handed back roughly 800–1,000 candidates and let you do the final match locally. When I hit that prefix, I got 1,977 hash suffixes back. Any one of them could have been "your" password. That's the anonymity set.

Doing it yourself in ~15 lines

No API key, no rate limit worth worrying about, and CORS is wide open so this runs fine from browser JavaScript. Here's the whole thing in Python so you can see there's no magic:

import hashlib, urllib.request

def pwned_count(password):
    h = hashlib.sha1(password.encode()).hexdigest().upper()
    prefix, suffix = h[:5], h[5:]
    url = f"https://api.pwnedpasswords.com/range/{prefix}"
    req = urllib.request.Request(url, headers={"User-Agent": "Mozilla/5.0"})
    body = urllib.request.urlopen(req).read().decode()
    for line in body.splitlines():
        s, count = line.split(":")
        if s == suffix:
            return int(count)
    return 0

print(pwned_count("password"))                  # 52372427
print(pwned_count("123456"))                     # 210461208
print(pwned_count("correcthorsebatterystaple"))  # 4173
print(pwned_count("xK9#mQ2vLp8$wZ4nR7tB"))       # 0

Those are real numbers I pulled today, not made up. A couple are worth sitting with. 123456 shows up 210 million times — the single most breached string on the internet. And the famous XKCD passphrase correcthorsebatterystaple? Pwned 4,173 times. The moment a password becomes advice, it becomes a dictionary entry. Randomness is the only thing that keeps you at zero.

The JavaScript version is nearly identical, using the built-in crypto.subtle.digest("SHA-1", ...):

async function pwnedCount(password) {
  const buf = await crypto.subtle.digest(
    "SHA-1", new TextEncoder().encode(password)
  );
  const hash = [...new Uint8Array(buf)]
    .map(b => b.toString(16).padStart(2, "0")).join("").toUpperCase();
  const prefix = hash.slice(0, 5), suffix = hash.slice(5);

  const res = await fetch(`https://api.pwnedpasswords.com/range/${prefix}`);
  const body = await res.text();
  for (const line of body.split("\n")) {
    const [s, count] = line.trim().split(":");
    if (s === suffix) return parseInt(count, 10);
  }
  return 0;
}

This is exactly the kind of thing SubtleCrypto is good at — unlike MD5, which the Web Crypto API flatly refuses to compute.

The padding option most people miss

There's a subtle leak in the basic scheme. Response sizes vary — a prefix might return 400 suffixes or 1,200. A network observer counting bytes can sometimes narrow down which prefix you requested, and popular prefixes correlate with common passwords.

HIBP added a fix: send the header Add-Padding: true and the server pads every response with a random number of fake, zero-count entries.

curl -s "https://api.pwnedpasswords.com/range/5BAA6" \
     -H "Add-Padding: true" -H "User-Agent: Mozilla/5.0"

# ...real entries...
DBB7A2BC0BCFAC5BF1E8B50FFC97A118303:0   ← decoy
...

When I added the header, the response grew from 1,977 to 2,122 lines — 144 of them decoys with a count of :0. Your matching code already ignores anything with count zero, so the padding is invisible to you but blows up traffic-analysis attacks. If you're building this into a product, turn padding on. It costs a few KB.

Why browser-only matters here

k-anonymity protects you from the HIBP server, but it doesn't protect you from your own backend if you route the check through it. The cleanest design is to hash and query entirely client-side, so the plaintext never leaves the tab.

That's the same principle behind every tool I build: the file, the password, the hash never touches a server I control. I wrote up the full teardown with a live browser demo here if you want to poke at the bytes yourself.

One thing this whole exercise reframed for me: a "check if breached" feature is only as trustworthy as its data flow. The clever part isn't the hashing — it's that the question itself is anonymized.

What's the sketchiest "we'll just send it to a third party to be safe" security feature you've seen ship? I've got a couple of horror stories.

Pasting a JWT Into an Online Base64 Decoder Is a Credential Leak — Here's the Browser-Only Fix

Max — Tue, 30 Jun 2026 17:02:29 +0000

Last month I watched a teammate debug an auth bug by pasting a production JWT into the first "base64 decode online" result on Google. The token was a live bearer credential — valid for another 50 minutes, signed for our payments service. He pasted it into a text box on a server he'd never heard of, hit decode, and read the payload. The bug got fixed. The token also got handed to a stranger's web server, where it sat in request logs neither of us will ever see.

That's the quiet problem with online base64 tools, and it's worth understanding why it happens — plus the two things even experienced devs get wrong when they try to skip the tool and just use the browser console.

Why pasting a JWT into a random decoder is a credential leak

A JWT is three base64url segments joined by dots: header, payload, signature. The first two decode to plain JSON. The third is the HMAC or RSA signature. Decoding it doesn't "crack" anything — but that misses the point: the whole string is the credential. If your decoder runs server-side, you just POSTed a working bearer token to a third party.

Most "free online" decoders are server-side. You can tell because:

they still work with JavaScript disabled, or
the network tab shows a request firing on every keystroke.

Some are honest hobby projects. Some are ad-funded and log everything. You have no way to know which, and "it's probably fine" is not a security model when the input is a live session token, an API key in a config blob, or a base64-encoded .env file.

The fix isn't a better-behaved server. It's not using a server at all. atob, btoa, and TextDecoder have shipped in every browser for years — the decode can happen entirely in your tab, with zero requests carrying your data. Open the network tab while a properly client-side tool decodes a 2 MB file and you'll see exactly that: nothing leaves.

The URL-safe gotcha that breaks the browser console

Here's the part that trips up even experienced devs. You might think "I don't need a tool, I'll just run atob() in the console." Try it on a real JWT segment and watch it throw.

// A JWT payload segment is base64URL, not standard base64
atob("eyJzdWIiOiIxMjM0NTY3ODkwIn0")  // ok here

// But base64url uses - and _ instead of + and /
// and usually drops the trailing = padding:
atob("-_-_Pj_4")
// Uncaught DOMException: Failed to execute 'atob':
// The string to be decoded is not correctly encoded.

Base64url swaps two characters from the standard alphabet: + becomes -, / becomes _, and trailing = padding is usually dropped. The browser's atob only understands the standard alphabet with correct padding, so it rejects exactly the strings you most often need to decode — JWTs, OAuth state params, anything that travels in a URL.

The fix is a normalization step on every decode:

function decode(str) {
  let n = str.replace(/-/g, '+').replace(/_/g, '/').replace(/\s/g, '');
  while (n.length % 4 !== 0) n += '=';      // re-add stripped padding
  const raw = atob(n);
  try { return decodeURIComponent(escape(raw)); }  // UTF-8 aware
  catch { return raw; }                            // fall back to raw bytes
}

Tested against the canonical jwt.io token: the header decodes to {"alg":"HS256","typ":"JWT"} and the payload to {"sub":"1234567890","name":"John Doe","admin":true,"iat":1516239022} — and the same input throws Invalid character through bare atob. That replace/repad dance is the whole reason a dedicated decode beats the raw console call.

The UTF-8 trap, and the emoji that proves it

The second thing naive decoders get wrong is multi-byte text. atob hands you a binary string where each character is one byte. Decode UTF-8 content like café and a naive reader shows you cafÃ©, because it's reading the two UTF-8 bytes for é as two separate Latin-1 characters.

The decodeURIComponent(escape(raw)) trick handles it: escape percent-encodes each byte, then decodeURIComponent reads those percent groups as UTF-8. Encoding runs the mirror image:

btoa(unescape(encodeURIComponent(data)))

It's an old idiom, but it round-trips correctly, and the try/catch means raw binary that isn't valid UTF-8 falls through untouched instead of corrupting silently. I ran a string of emoji through encode → decode and got byte-identical output the other side.

Where browser-only beats the command line too

I live in a terminal, so I'll be honest about when base64 -d is the right call: scripting, pipes, CI. But three things push me back to a browser tab more often than I expected.

Auto-detect direction. Paste base64, it decodes; paste plain text, it encodes. No flipping a -d flag and re-running.
Per-line mode. A file of base64 strings, one per line, decodes row-by-row instead of being treated as one stream. macOS base64 won't do that without a while read loop.
Image preview. Paste a data:image/png;base64,... URI and render the actual image — the fastest way to sanity-check an inline asset.

And if it's a PWA with a service worker, it works offline: load it once, kill wifi, still decodes — exactly the posture you want for a tool that touches secrets.

The honest limitation

Base64 is encoding, not encryption. Decoding a JWT shows you the claims; it does not verify the signature or let you forge one. If you need to validate signatures or test signing keys, that's a different job — reach for a proper JWT library, not a base64 tool.

If you want a client-side one to poke at, I put the working version of all of the above (base64url normalization, UTF-8 round-trip, per-line, image preview, offline) into a free browser-only tool: Base64Lab. Network tab stays empty by construction. Full write-up with the byte-level details is here.

What's the worst credential you've watched someone paste into a random online tool? I'll start: a live Stripe restricted key, into a "JSON pretty print" site, on a shared screen.

Reverse-Engineering SEC EDGAR's Full-Text Search API (One Undocumented GET Request)

Max — Tue, 23 Jun 2026 17:04:58 +0000

The official SEC EDGAR full-text search box is great if you're a human clicking around. It's useless if you want to pull 200 filings that mention "going concern" into a script.

So I opened the network tab, watched what the search page actually calls, and rebuilt the request myself. It turns out the entire thing runs on one undocumented GET request that returns clean Elasticsearch JSON. No API key, no signup, no OAuth dance. The SEC quietly shipped one of the better free financial-data APIs and never put a docs page on it.

Here's the exact request, the response fields nobody explains, and the gotchas that cost me an afternoon.

The endpoint and its real parameters

The page is a thin React front end. Every search fires a GET to https://efts.sec.gov/LATEST/search-index and gets back raw Elasticsearch JSON.

One trap before you copy anything: the path casing matters. /LATEST/ is uppercase; a lowercase /latest/ 404s.

The query parameters that actually do something:

q — the search term. Wrap a phrase in URL-encoded double quotes (%22climate+risk%22) for an exact match, or it tokenizes into an OR search.
forms — comma-separated filing types: 10-K, 8-K, SC 13D, etc. Leave it off to search everything.
startdt and enddt — date bounds in YYYY-MM-DD. Both required if you want a window.
from — pagination offset.
ciks — restrict to a specific company by its zero-padded CIK number.

A complete request:

curl -s \
  -A "your-app your-email@example.com" \
  "https://efts.sec.gov/LATEST/search-index?q=%22machine+learning%22&forms=8-K&startdt=2026-01-01&enddt=2026-06-01"

The User-Agent header is not optional. SEC's fair-access policy rejects requests with a generic or empty agent — you'll get a 403. Put your app name and a contact email in there. I learned this the hard way after my first ten curls returned nothing but an HTML block page.

The two fields that unlock everything

The response is the Elasticsearch envelope, untouched. A single hit looks like this:

{
  "_id": "0001193125-26-032000:ionq-ex99_2.htm",
  "_source": {
    "ciks": ["0001824920"],
    "display_names": ["IonQ, Inc.  (IONQ)  (CIK 0001824920)"],
    "root_forms": ["8-K"],
    "form": "8-K",
    "file_date": "2026-01-30",
    "adsh": "0001193125-26-032000",
    "file_type": "EX-99.2"
  }
}

Two fields do all the work:

_id is {accession}:{filename}. Split on the colon and you can build a direct link to the document.
adsh is the accession number — the join key you feed into the rest of EDGAR's data and XBRL endpoints to pull the full filing.

Turning a hit into a clickable filing URL means stripping the dashes from the accession number for the folder path:

def filing_url(hit):
    adsh, fname = hit["_id"].split(":", 1)
    cik = int(hit["_source"]["ciks"][0])  # int() drops leading zeros
    folder = adsh.replace("-", "")
    return f"https://www.sec.gov/Archives/edgar/data/{cik}/{folder}/{fname}"

A few _source fields are worth knowing because the docs never mention them:

items — 8-K item codes. This is the fast filter for event-driven work: 2.02 is earnings, 5.02 is an exec change, 1.01 is a material agreement.
root_forms — use this, not form, when you want amendments grouped with originals (8-K/A rolls up under 8-K).
file_date vs period_ending — filing date vs the period the filing covers. For "what was disclosed today" you want file_date; for fundamentals you want period_ending.
display_names — a pre-formatted Name (TICKER) (CIK …) string. Regex the ticker out instead of doing a second lookup.

There's also a free bonus: every response carries an aggregations block with form_filter, entity_filter, sic_filter, and biz_states_filter faceted counts — whether you asked for them or not. You can build a filings dashboard's sidebar without a single extra request.

A scraper that actually paginates

Pagination is the one thing that trips people up. Each request returns at most 100 documents in hits.hits; there's no size parameter the backend honors past that. You walk the result set with from, step by 100, and watch hits.total.value for when to stop.

import time
import requests

EFTS = "https://efts.sec.gov/LATEST/search-index"
HEADERS = {"User-Agent": "orthogonal-research max@orthogonal.info"}

def search_all(q, forms=None, startdt=None, enddt=None, max_results=1000):
    results = []
    offset = 0
    while offset < max_results:
        params = {"q": q, "from": offset}
        if forms:   params["forms"] = forms
        if startdt: params["startdt"] = startdt
        if enddt:   params["enddt"] = enddt

        r = requests.get(EFTS, params=params, headers=HEADERS, timeout=15)
        r.raise_for_status()
        hits = r.json()["hits"]["hits"]
        if not hits:
            break
        results.extend(hits)
        offset += 100
        time.sleep(0.15)  # stay under ~10 req/sec
    return results

filings = search_all('"going concern"', forms="10-K",
                     startdt="2026-01-01", enddt="2026-06-01")
for f in filings:
    src = f["_source"]
    print(src["file_date"], src["form"], src["display_names"][0])

The time.sleep(0.15) keeps you under SEC's documented limit of ~10 requests/sec. Go faster and you'll get temporary IP blocks lasting about ten minutes. There's no X-RateLimit header to watch — the only signal is a sudden 403, so it's better to throttle up front than to detect and back off.

The gotchas that cost me time

Phrase vs token search. A bare q=climate risk matches documents containing "climate" OR "risk" anywhere — that returned 40x more noise than I expected. The quoted form q=%22climate risk%22 is the exact phrase, and it's what you almost always want.
The 10,000-result ceiling. Elasticsearch caps deep pagination. Once from passes 10,000 the endpoint errors out. If a query has more hits than that, narrow it with a tighter date range and stitch the windows together — there's no scroll cursor exposed.
Full-text only covers 2001 onward. The index starts in 2001. Older filings exist in EDGAR but won't show up here; for pre-2001 you're back to the structured submissions API.
It indexes exhibits, not just the main doc. A single 8-K can return several hits — one per attached exhibit. Dedupe on the accession number (adsh) if you only want one row per filing.

Where this fits

I use this as the front door for a couple of projects: a script that flags new 8-K filings mentioning specific risk language, and an insider-buying alerter that cross-references full-text hits against Form 4 data. The full-text endpoint finds the filings; the structured EDGAR APIs pull the details.

I wrote up the full field-by-field decode of the _source envelope (every key in a real forms=8-K response) here if you want the complete reference.

The whole thing is one undocumented GET request returning clean JSON — no key, no cost. What other "human-only" search boxes are quietly sitting on a clean JSON API? I keep finding them in network tabs.

Why Math.random() Is a Security Bug in Password Generators (and the Web Crypto Fix)

Max — Thu, 11 Jun 2026 17:04:37 +0000

Last week I was reviewing a small auth service and found this one-liner generating password-reset tokens:

const token = Array.from(
  { length: 16 },
  () => CHARS[Math.floor(Math.random() * CHARS.length)]
).join('');

It runs. It produces things like xK9$mLp2@nQ7vR4w. It also happens to be a real security bug.

That exact pattern is the one I deliberately avoided when I built a small browser-only password generator — and the reason is worth a few hundred words, because almost every "roll your own" password snippet on the web gets it wrong in the same way. Here's what's broken about Math.random() for secrets, the fix, and the two gotchas that bite people who try to fix it themselves.

`Math.random()` is predictable by design

In V8 — the engine behind Chrome and Node — Math.random() has used an algorithm called xorshift128+ since version 4.9.40 (late 2015). It has 128 bits of internal state, a period of 2^128 − 1, and it passes the TestU01 statistical suite. Statistically, the numbers look random.

But "looks random" and "unpredictable" are different properties.

xorshift128+ is a pseudo-random generator: every output is a deterministic function of that 128-bit state, and the state is recoverable. Feed enough consecutive outputs into a system of linear equations and you can solve for the internal state — there are public tools on GitHub that recover it from as few as 64–128 consecutive Math.random() calls. Once an attacker has the state, every future output is known. Every "random" password you generate after that point is predictable.

For a UI animation or a Monte Carlo sim, who cares. For a password, an API key, or a session token, that's the whole ballgame.

`crypto.getRandomValues()` is the actual fix

Browsers ship a cryptographically secure RNG (CSPRNG) through the Web Crypto API. It pulls from the OS entropy pool (/dev/urandom on Linux, BCryptGenRandom on Windows) and is built so that observing past output tells you nothing about future output. There's no recoverable internal state to solve for.

The core is four lines:

function secureRandom(max) {
  const arr = new Uint32Array(1);
  crypto.getRandomValues(arr);
  return arr[0] % max;
}

Read a fresh 32-bit unsigned integer from the CSPRNG, reduce it into the range you need, done. Swap Math.random() for this and the prediction attack above is gone.

But notice that % max — that's gotcha number one.

Gotcha 1: modulo bias is real (but size matters)

When you take a random integer modulo your alphabet size, the ranges usually don't divide evenly, so some characters come up more often than others. I wanted to see how bad it actually is, so I generated 6.2 million random bytes and bucketed byte % 62 (a typical alphanumeric set):

expected per character: 100,000
lowest-frequency char: ~96,900 hits
highest-frequency char: ~121,400 hits
ratio: 1.25 — a 25% skew

It happens because 256 % 62 = 8, so byte values 0–7 each give one extra shot to the first eight characters.

The textbook fix is rejection sampling: throw away any byte in the biased tail and draw again. Rejecting values ≥ 248 dropped the skew to a 1.02 ratio in my test, at the cost of discarding about 3.1% of draws.

But here's the part the "always use rejection sampling" advice skips: the bias depends entirely on how big your random integer is relative to the alphabet. If you don't read a single byte but a full Uint32 (range 0 to ~4.29 billion), then for a 94-character symbol set, Uint32 % 94 makes the favored characters more likely by roughly 1 part in 45 million — a bias of 0.0000022%.

For a password, that's noise far below anything that matters. So you can skip rejection sampling on purpose and keep the code simple, because a 32-bit draw already makes the bias irrelevant. If you're minting cryptographic keys, add the rejection step; for human passwords, a wide draw is enough.

Gotcha 2: the 64KB quota wall

The second surprise showed up while running that bias test. My first attempt asked getRandomValues() to fill one big buffer:

crypto.getRandomValues(new Uint8Array(620000));
// QuotaExceededError: The requested length exceeds 65,536 bytes

getRandomValues() refuses any request over 65,536 bytes (64 KB) in a single call. It's in the spec and every browser enforces it. If you're generating one 16-character password you'll never hit it, but the moment you batch-generate or fill a large buffer, you have to chunk:

function fillSecure(buf) {
  for (let i = 0; i < buf.length; i += 65536) {
    crypto.getRandomValues(buf.subarray(i, i + 65536));
  }
}

Undocumented in most tutorials, and a hard failure rather than a silent one — which is at least honest of it.

Why browser-only matters here

A password generator that does the work server-side is a service that has seen your password in plaintext. The only design that makes sense for a secret is to build it on the user's machine, from their OS entropy, so it never touches a network. Open dev tools, watch the Network tab while you click generate, and you should see exactly zero requests.

If you want to poke at a working version, here's the browser-only password generator I built around these exact decisions — everything runs client-side.

One layer is never enough

A strong, truly-random password fixes the "guessable" problem. It does nothing about phishing, reused credentials, or a leaked database. Generate unique passwords, store them in a real manager, and gate the important accounts with hardware 2FA. Three cheap layers beat one strong one.

The lesson I keep relearning: in security, the code that "works" and the code that's correct are often the same length and completely different.

Math.random() works. crypto.getRandomValues() is correct.

How do you handle modulo bias in your own token/ID generators — always reject, or do you size the draw so it doesn't matter? Curious what others do in practice.

How to Compress Images From the Command Line (and in CI) — No Upload, No Account

Max — Tue, 09 Jun 2026 15:24:08 +0000

Most "compress your images" advice ends with "...now drag your files into this website." That's fine for a one-off. It's useless when you have a /public/images folder with 300 PNGs, or a build step that should never ship a 4 MB hero image again.

I wanted image compression that lives where the rest of my tooling lives: the terminal and CI. No upload, no account, no clicking. Here's the workflow I landed on, plus a tiny CLI I built to make it one command.

The problem with web-based compressors in a dev workflow

TinyPNG, Squoosh, and friends are great tools. But in a real project they have three issues:

They don't script. You can't put "open a browser and drag files" in a package.json or a GitHub Action.
They upload. For a lot of teams, shipping customer/product images to a third-party server is a non-starter.
They're one-at-a-time-ish. Batch + recursive folders + keeping structure is exactly the boring part you want automated.

What you actually want: compress ./images → done, locally, every time.

Option 1: raw `sharp` in a script

If you just want the engine, sharp (libvips bindings) is the workhorse. A minimal batch script:

// compress.js
import sharp from "sharp";
import { glob } from "glob";
import path from "node:path";
import fs from "node:fs/promises";

const files = await glob("images/**/*.{jpg,jpeg,png}");
await fs.mkdir("dist", { recursive: true });

for (const file of files) {
  const out = path.join("dist", path.basename(file, path.extname(file)) + ".webp");
  await sharp(file)
    .resize({ width: 1600, withoutEnlargement: true })
    .webp({ quality: 80 })
    .toFile(out);
  console.log("✓", out);
}

This works. But you'll quickly want flags (quality, format, max-width), parallelism across cores, "don't enlarge," metadata stripping, dry-run, and preserved folder structure — and now you're maintaining a tool instead of shipping your app.

Option 2: a tiny CLI that already does all that

So I packaged exactly that into a small, MIT-licensed CLI called QuickShrink. It's a thin, well-tested wrapper over sharp, focused on the batch-folder workflow. Run it once with npx, no global install:

# compress every image in ./images → ./compressed
npx https://quickshrink.orthogonal.info/cli/quickshrink.tgz ./images

Convert a whole folder to WebP and cap the width for web (the single most impactful thing you can do for page weight):

npx https://quickshrink.orthogonal.info/cli/quickshrink.tgz ./photos \
  -o ./web --format webp --max-width 1600 --quality 80

Recurse into subfolders and keep the structure:

npx https://quickshrink.orthogonal.info/cli/quickshrink.tgz ./assets -o ./out --recursive

Preview before you touch anything:

npx https://quickshrink.orthogonal.info/cli/quickshrink.tgz ./photos --dry-run

Typical output:

  ✓ out/hero.webp        1.38 MB → 42.7 KB  (-97%)
  ✓ out/sub/banner.webp  3.10 MB → 31.1 KB  (-99%)

Done: 2 ok, 0 failed.
Total: 4.47 MB → 73.8 KB  (saved 4.40 MB, 98.4%)

Flags it supports:

Flag	Does
`-o, --out <dir>`	Output directory (default `./compressed`)
`--format <fmt>`	`jpeg` \
`--quality <1-100>`	Encoder quality (default 80)
`--max-width` / `--max-height`	Resize down, never up
`--recursive`	Walk subfolders
`--dry-run`	Show the plan, write nothing

Everything runs locally — your images never leave the machine. It uses all your CPU cores and strips metadata by default.

Option 3: wire it into CI

Because it's a single command, dropping it into a GitHub Action is trivial. Here's a step that compresses everything under public/images and fails loudly if compression errors:

# .github/workflows/images.yml
name: Compress images
on:
  pull_request:
    paths: ["public/images/**"]

jobs:
  shrink:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20 }
      - name: Compress images
        run: |
          npx -y https://quickshrink.orthogonal.info/cli/quickshrink.tgz \
            ./public/images -o ./public/images --format webp --max-width 1600
      - name: Commit if changed
        run: |
          git config user.name "image-bot"
          git config user.email "bot@users.noreply.github.com"
          git add -A
          git diff --cached --quiet || git commit -m "chore: compress images"
          git push

Now nobody on the team can accidentally ship a 4 MB screenshot again. The bot quietly WebP's and resizes on every PR that touches images.

A package.json shortcut

For local use, alias it so teammates don't need to remember the URL:

{
  "scripts": {
    "images": "npx -y https://quickshrink.orthogonal.info/cli/quickshrink.tgz ./src/assets -o ./public/img --format webp --max-width 1600"
  }
}

npm run images and you're done.

What about serverless / "I can't install native deps"?

sharp ships prebuilt binaries, so the CLI works in most CI runners and locally. The one place it gets awkward is constrained serverless functions or runtimes where native libs are a pain. For that case I'm building a small hosted compression API (key-based, metered) so you can POST an image and get bytes back without bundling libvips. It's in private beta — if that's your use case, there's a note + email on the CLI page and I'd genuinely like the feedback on what limits/pricing make sense.

Prefer a GUI for one-offs?

For the occasional "just shrink this one screenshot" moment, there's a browser version that does the same thing client-side (the compression runs in your browser via Canvas — also no upload). But for anything repeatable, the CLI is the move.

TL;DR:

npx https://quickshrink.orthogonal.info/cli/quickshrink.tgz ./images --format webp --max-width 1600

Local, scriptable, batch, free, MIT. That's the whole pitch. If you put it in CI, I'd love to hear how it goes — and what flag you wish it had next.

Your Online SQL Formatter Might Be Logging Your Database Password

Max — Thu, 04 Jun 2026 17:03:46 +0000

Last month I watched a contractor paste a full Kubernetes secret manifest — base64 blobs and all — into the first "free YAML validator" that came up on Google. He just wanted to check the indentation. What he actually did was POST a production database password to a server he'd never heard of, run by people he'll never meet, with a privacy policy he didn't read.

That's the part of online dev tools nobody talks about.

A SQL formatter, a YAML validator, a JSON beautifier — they feel disposable, like a calculator. But a huge number of them send whatever you paste to a backend for processing. If that paste contains a connection string, an API key, or a customer record, you just leaked it. No breach required. You handed it over.

Why "format my SQL" is a data exfiltration path

Here's the mechanic. Server-side tools work like this: your text goes into a <textarea>, JavaScript fires an HTTP request to /api/format, the server runs the actual formatting, and the result comes back. Simple to build, which is exactly why so many sites do it that way.

The problem is what travels in that request body.

I tested a handful of popular online formatters with my browser's Network tab open. Several of them sent the entire input payload to their own domain. One sent it to a third-party API. The query I pasted was harmless test data, but the request was real — my text left my machine.

Now picture the realistic version. You're debugging a failing migration at 11pm. You copy the offending query straight out of your ORM logs to "just clean it up." That query has a hardcoded credential a teammate left in six months ago. You paste, you format, you move on.

The credential is now in someone's request logs, maybe their analytics, maybe an LLM training pipeline if the tool resells data. You will never know.

This isn't paranoia. It's the same threat model that makes pasting code into random pastebins a fireable offense at most security-conscious shops. We just don't apply it to "format" tools because they feel too small to matter.

How to actually verify a tool is client-side

Don't take any tool's word for it — including the one I'm about to mention. Verifying is a two-minute job and every developer should know how.

1. Watch the Network tab. Open DevTools (F12), go to the Network panel, clear it, then paste your text and hit format. If you see a new XHR/fetch request fire with your input in the payload, the tool is server-side. If nothing happens on the network, the work is local.

// What a server-side formatter looks like in the Network tab:
POST /api/format-sql
Request Payload:
{ "query": "SELECT * FROM users WHERE token='sk_live_...'" }

// What a client-side tool looks like:
// (nothing — no request fires when you click format)

2. Kill your connection. The bluntest test there is. Load the page, then turn off Wi-Fi or drop into airplane mode. If the tool still formats your text, it's running entirely in the browser. If it spins or errors, it needed a server. I do this with any tool before I trust it with anything sensitive.

3. Check for a service worker. Truly offline-capable tools register a service worker so they work with no connection at all. In DevTools, look under Application → Service Workers. Its presence is a strong signal the developer designed for offline-first, which usually means client-side processing too.

Where this fits in a real workflow

A few concrete cases where I reach for browser-only tools specifically because of the data:

Reviewing a teammate's config PR. Diffing two Helm values files that contain registry credentials — done locally, nothing logged anywhere.
Cleaning up a query from prod logs. Format it to read it, without shipping whatever sensitive WHERE clause it carries to a stranger's server.
Validating a CI secrets file. Checking that a GitHub Actions YAML parses before you commit, without exposing the encrypted values to a validation API.
On a locked-down network. Some client environments block external dev-tool domains entirely. Offline-capable tools just keep working.

The broader point: treat every "paste your text here" box as a potential outbound network call until you've proven otherwise. Most of the time it's fine. The one time it isn't, it's a leaked credential you can't un-leak.

The structural fix

The fix is structural, not procedural. Don't rely on remembering to scrub secrets first — use tools that physically can't send your data anywhere, because all the work happens in your tab.

That's the reason I built our formatters as single-file, client-side apps — a SQL Formatter, a YAML Validator, and a Diff Checker where the parsing runs in JavaScript on your device. There is no /api/format endpoint. The text in your textarea never crosses the network because there's nowhere for it to go.

But browser-only tools only remove one exfiltration path. Defense in depth still applies: rotate the credentials that have already been pasted into who-knows-what, and put a pre-commit secret scanner in front of your repos so the hardcoded ones never ship in the first place.

How do you handle this on your team — do you have a policy on pasting into online dev tools, or is it the wild west? Curious what threat models other people apply here.

I Made an Image Compressor That Never Sees Your Images (100% Client-Side)

Max — Fri, 29 May 2026 15:02:23 +0000

Ever notice how most "free" image compressors upload your files to their servers?

I got fed up with this — especially when compressing screenshots that might contain sensitive data — so I built QuickShrink: an image compressor that runs entirely in your browser.

Why client-side matters

Privacy: Your images never leave your device
Speed: No upload/download round-trip. Compression is instant
Works offline: It's a PWA. Install it and use it without internet
No account needed: Just drag, drop, done

What it does

Compress JPEG/PNG/WebP with adjustable quality (1-100)
Batch compress multiple images at once
Convert between formats (PNG to WebP for 60-80% size reduction)
Resize images with aspect ratio lock
See before/after comparison with file sizes

The tech

Built with vanilla JavaScript + Canvas API + OffscreenWorker for non-blocking compression. The entire app is about 50KB. No React, no framework, no build step.

Try it

quickshrink.orthogonal.info

Free tier: 5 compressions/day
Pro: Unlimited + batch + format conversion ($4.99 one-time)

I'd love feedback on compression quality vs file size. Is the default quality slider (80%) a good default for web images?

Built this as a weekend project after TinyPNG's free tier dropped to 20 images/month. If you're compressing screenshots or blog images regularly, give it a shot.

Why I Stopped Uploading Images to Compression Services (And Built a Browser-Only Alternative)

Max — Thu, 28 May 2026 17:01:55 +0000

The Problem

Every web developer has been there: you need to compress images for a client project, so you drag them to TinyPNG or some random compression site.

But then you pause. These are mockups with unreleased branding. Or screenshots with sensitive data. Or client photos under NDA.

Do you really want to upload them to a third-party server?

I started thinking about this more seriously after GDPR enforcement got real. If you're processing client images through external services, that's technically data processing you need to account for.

The Browser Can Do This Now

Modern browsers ship with Canvas API, OffscreenCanvas, and WebAssembly support that makes client-side image processing genuinely fast. We're not talking about the janky Canvas-based compression from 2015 — WASM codecs for WebP and AVIF run at near-native speed now.

The key insight: your browser is already an image processing engine. It decodes every image you view. Why upload somewhere else just to re-encode it smaller?

What I Built

I made QuickShrink — a free image compressor that runs 100% in your browser:

Drag and drop (or paste from clipboard)
Images never leave your machine
No accounts, no limits, no upsells
Handles PNG, JPEG, WebP
Batch processing supported

The entire thing is static HTML/JS. You could literally save the page and run it offline.

Technical Approach

The compression pipeline:

Read file as ArrayBuffer
Decode to ImageBitmap (hardware-accelerated)
Draw to OffscreenCanvas at target quality
Export as compressed blob
Trigger download

For most photos, you get 60-80% size reduction at quality 0.8 with zero perceptible difference. For PNGs with transparency, re-encoding as WebP typically saves 40-60%.

When You Should Still Use Server-Side

To be fair, client-side isn't always the answer:

Build pipelines: Use Sharp/libvips in your CI for automated optimization
CDN transforms: Cloudflare/Imgix handle format negotiation per-device
Bulk processing: 10,000 images? Use a proper batch tool

But for the everyday "I need to shrink these 5 screenshots before adding them to the README" — a browser tool is faster and more private than any upload-based service.

Try It

quickshrink.orthogonal.info — open source, free forever, no tracking.

Would love feedback from folks who've built similar tools. What codecs are you using? Anyone gotten JPEG XL working reliably in-browser yet?

If you found this useful, I write about web performance and developer tools at orthogonal.info.

How to Optimize Images for Website Speed in 2026 (Without Losing Quality)

Max — Thu, 28 May 2026 15:03:17 +0000

Images account for ~50% of total page weight on most websites. If your site loads slowly, images are almost certainly the bottleneck.

After years of optimizing web performance, here's my complete workflow for image optimization in 2026.

Why Image Optimization Matters

Core Web Vitals: Google uses LCP (Largest Contentful Paint) as a ranking signal. Unoptimized hero images = slow LCP = lower rankings.
Bounce rate: 53% of mobile users leave if a page takes >3 seconds to load.
Bandwidth costs: Smaller images = less CDN/hosting cost.

The 4-Step Image Optimization Workflow

1. Choose the Right Format

Format	Best For	Browser Support
WebP	Photos, illustrations	97%+
AVIF	Photos (best compression)	~92%
PNG	Transparency, icons	100%
SVG	Logos, simple graphics	100%

Rule of thumb: Use WebP for everything unless you need transparency (PNG) or have vector graphics (SVG).

2. Resize Before Compressing

Never serve a 4000px image in a 800px container. Resize first:

<img 
  srcset="image-400.webp 400w, image-800.webp 800w, image-1200.webp 1200w"
  sizes="(max-width: 600px) 400px, (max-width: 1000px) 800px, 1200px"
  src="image-800.webp"
  alt="descriptive alt text"
  loading="lazy"
  decoding="async"
/>

3. Compress Aggressively

Most images look identical at 75-80% quality. The sweet spot:

Hero images: 80-85% quality
Thumbnails: 70-75% quality
Background images: 60-70% quality

I use QuickShrink for this because:

It runs entirely in the browser (no upload = no privacy risk)
Supports batch compression
Lets you compare before/after side by side
Works offline once loaded

4. Lazy Load Everything Below the Fold

<!-- Above the fold: load immediately -->
<img src="hero.webp" fetchpriority="high" />

<!-- Below the fold: lazy load -->
<img src="gallery-1.webp" loading="lazy" decoding="async" />

Quick Wins Checklist

[ ] Convert all JPEGs to WebP (30-50% smaller)
[ ] Add loading="lazy" to images below the fold
[ ] Add width and height attributes (prevents layout shift)
[ ] Use srcset for responsive images
[ ] Compress to 75-80% quality
[ ] Add fetchpriority="high" to LCP image

Tools I Recommend

QuickShrink — Free, browser-based, no upload needed. My go-to for quick compression.
Sharp (Node.js) — For build pipelines and automation.
Squoosh CLI — Google's tool for batch processing.

Real Results

On a recent client site, following this workflow:

Page weight: 4.2MB → 890KB (79% reduction)
LCP: 4.1s → 1.3s
PageSpeed score: 62 → 94

TL;DR

Use WebP format
Resize to display dimensions
Compress to 75-80% quality (try QuickShrink)
Lazy load below-the-fold images
Add width/height to prevent layout shift

Doing just steps 1-3 typically cuts image size by 70%+.

What's your image optimization workflow? Drop it in the comments — always looking for new tricks.

TinyPNG vs QuickShrink: Why I Switched to Client-Side Image Compression

Max — Wed, 27 May 2026 15:03:51 +0000

Every web developer knows TinyPNG. It's been the go-to image compressor for years. But after years of using it, I started questioning: why am I uploading my images to someone else's server?

The Problem with Server-Side Compression

Tools like TinyPNG, Compressor.io, and even Squoosh (partially) require you to upload images to their servers. For most casual use, that's fine. But consider:

NDA projects — client mockups, unreleased product photos
Medical/legal images — patient data, case evidence
Personal photos — family photos you want smaller but private
Enterprise work — screenshots of internal dashboards, Slack messages

Every upload is a data transfer you can't take back.

What is Client-Side Compression?

Instead of sending your image to a server for processing, client-side compression uses your browser's built-in Canvas API and WebP encoding to compress images locally. The file never leaves your device.

Open DevTools → Network tab → compress an image → zero outgoing requests. That's the proof.

Comparison: TinyPNG vs QuickShrink

Feature	TinyPNG	QuickShrink
Privacy	Server-side (images uploaded)	100% client-side
Batch	Yes (20 images, 5MB each)	Yes (unlimited size)
WebP output	No (PNG/JPEG only)	Yes
Resize	No	Yes
Quality presets	No (auto only)	Web, Social, Email, Print
Offline	No	Yes (PWA)
API	Yes ($)	Coming soon
Price	Free (20/day) or 9/yr	Free (5/day) or .99/mo

Compression Quality

Let's be honest — TinyPNG's lossy PNG compression is excellent. Their algorithm (quantization + DEFLATE) produces incredibly small PNGs with minimal quality loss.

QuickShrink uses Canvas API resampling + WebP encoding, which takes a different approach:

JPEG → WebP: typically 40-60% smaller at equivalent quality
PNG → WebP: typically 50-80% smaller (lossy WebP vs lossless PNG)
JPEG → JPEG: 20-40% smaller with quality adjustment

The tradeoff: TinyPNG gives better PNG-to-PNG results. QuickShrink wins when you convert to WebP (which you should for web use in 2024+).

When to Use Which

Use TinyPNG when:

You need PNG output specifically
Images aren't sensitive
You want the absolute smallest PNG

Use QuickShrink when:

Privacy matters (NDAs, sensitive content)
You want WebP output (better web performance)
You need resize + compress in one step
You want offline capability
You don't want to create an account

Try It

QuickShrink — free, no signup, works in any modern browser.

What's your image compression workflow? Still uploading to servers, or have you gone client-side?

I Caught 14 Leaked Secrets in My Git History — Here is the Pre-Commit Setup That Stops It

Max — Tue, 26 May 2026 17:03:43 +0000

Last month I ran trufflehog against one of my private repos — a homelab automation project I’d never planned to open-source. It found 14 live secrets. AWS keys, a Telegram bot token, two database passwords, and a Stripe test key that still had access to customer data. All committed between 2022 and 2024, scattered across dozens of commits.

The fix took me about 20 minutes. I now run two tools as pre-commit hooks that catch secrets before they ever reach .git/objects. Here’s exactly how I set it up, what each tool catches that the other misses, and the one configuration mistake that will give you false confidence.

Why Two Tools: git-secrets vs trufflehog

I use both git-secrets and trufflehog because they work differently and catch different things.

git-secrets is pattern-based. It ships with AWS-specific patterns out of the box (matches AKIA[0-9A-Z]{16} and similar) and lets you add custom regexes. It’s fast — sub-100ms on most commits — and runs as a native git hook. The downside: it only knows what you tell it to look for.

trufflehog uses entropy detection and pattern matching. It calculates Shannon entropy on strings and flags anything that looks random enough to be a key. Version 3 also verifies secrets against live APIs — it’ll actually try your AWS key against STS to confirm it’s active. This is slower (2-5 seconds per commit) but catches novel secret formats that pattern matching misses.

In my 14-secret audit, git-secrets would have caught 9 of them. trufflehog caught all 14. But git-secrets has zero false positives in my workflow, while trufflehog flags about 1 false positive per week on base64-encoded config blobs.

Setting Up git-secrets as a Pre-Commit Hook

Install it:

brew install git-secrets   # macOS
# or
git clone https://github.com/awslabs/git-secrets.git
cd git-secrets && make install

cd your-repo
git secrets --install
git secrets --register-aws

That --register-aws flag adds patterns for AWS access keys, secret keys, and account IDs. Now add your own patterns for whatever services you use:

# Telegram bot tokens (numeric:alphanumeric format)
git secrets --add '[0-9]{8,10}:[A-Za-z0-9_-]{35}'

# Stripe keys
git secrets --add 'sk_(live|test)_[A-Za-z0-9]{24,}'

# Generic high-entropy passwords in connection strings
git secrets --add 'password\s*=\s*[^\s]{12,}'

Test it works:

echo "AKIAIOSFODNN7EXAMPLE" > test.txt
git add test.txt
git commit -m "test"
# Output: [ERROR] Matched one or more prohibited patterns

One gotcha: git secrets --install only sets up hooks in that repo. For global coverage across all repos:

git secrets --install ~/.git-templates/git-secrets
git config --global init.templateDir ~/.git-templates/git-secrets

Adding trufflehog as a Pre-Commit Hook

I use the pre-commit framework for trufflehog since it handles updates and version pinning:

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/trufflesecurity/trufflehog
    rev: v3.78.1
    hooks:
      - id: trufflehog
        entry: trufflehog git file://. --since-commit HEAD --only-verified --fail
        stages: [commit, push]

The --only-verified flag is important. Without it, trufflehog reports every high-entropy string — UUIDs, hashes, random test data. With it, you only get alerts for secrets that are confirmed active against their respective APIs. This drops false positives from ~30/week to about 1.

Install and activate:

pip install pre-commit
pre-commit install
pre-commit install --hook-type pre-push

The Configuration Mistake That Gives False Confidence

Here’s what tripped me up for months: git-secrets only scans staged changes by default, not the full file. If you have a secret on line 5 and you modify line 50, git-secrets won’t flag it because line 5 isn’t in the diff.

This matters because secrets often enter a file in one commit and stay there forever. The pre-commit hook only fires on new changes, so existing secrets remain invisible.

Fix: run a full-repo scan on a schedule. I have this in a weekly cron:

# Scan entire repo history
trufflehog git file:///path/to/repo --only-verified --json > /tmp/secrets-audit.json

# Scan all current files (not just diffs)
git secrets --scan

I pipe the output to ntfy for notifications. If something shows up, I rotate the credential immediately and use git filter-repo to purge it from history:

git filter-repo --invert-paths --path secrets.env
# Then force-push and tell collaborators to re-clone

What About GitHub’s Built-in Secret Scanning?

GitHub’s secret scanning (free for public repos, paid for private) is solid but it’s a safety net, not prevention. By the time GitHub alerts you, the secret has already been pushed to a remote. If your repo was public for even 5 seconds, bots have already scraped it — I’ve seen AWS keys exploited within 4 minutes of being pushed.

Pre-commit hooks stop the secret locally. That’s the difference between “we caught it early” and “we need to rotate everything and audit CloudTrail logs.”

My Full .pre-commit-config.yaml

Here’s what I run on every project now:

repos:
  - repo: https://github.com/trufflesecurity/trufflehog
    rev: v3.78.1
    hooks:
      - id: trufflehog
        entry: trufflehog git file://. --since-commit HEAD --only-verified --fail
        stages: [commit, push]

  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.4
    hooks:
      - id: gitleaks
        stages: [commit]

I actually dropped git-secrets from the pre-commit config because gitleaks covers similar patterns with better regex coverage and active maintenance. I still keep git-secrets installed globally as a backup layer — defense in depth.

Total overhead per commit: ab

I Built a Free Client-Side Image Compressor (No Upload, Works Offline)

Max — Tue, 26 May 2026 15:02:21 +0000

I got tired of uploading sensitive images to servers just to compress them. TinyPNG is great but requires server upload. Squoosh only does one image at a time.

So I built QuickShrink — a browser-based image compressor where everything happens client-side. Your images never leave your device.

What it does

Client-side compression — uses Canvas API + WebP encoding in-browser
Batch processing — drag multiple files, compress all at once
WebP output — 30-50% smaller than JPEG at same quality
Resize + compress — set max dimensions
Quality presets — Web, Social Media, Email, Print
PWA — install it, works offline

Why client-side matters

If you are compressing screenshots with credentials, internal docs, or client work — you probably do not want them hitting someone elses server. With QuickShrink, the files stay in your browser tab.

Try it

quickshrink.orthogonal.info

Free tier: 5 images/day. Pro (4.99/mo): unlimited + priority features.

Tech stack

Vanilla JS, Canvas API, Web Workers for non-blocking compression, Service Worker for offline support. No framework, loads in under 1 second.

Would love feedback from fellow devs. What features would make this more useful for your workflow?

DEV Community: Max

Check If a Password Was Breached Without Sending It (HIBP k-Anonymity)

The problem with a naive breach check

How the range API actually works

Doing it yourself in ~15 lines

The padding option most people miss

Why browser-only matters here

Pasting a JWT Into an Online Base64 Decoder Is a Credential Leak — Here's the Browser-Only Fix

Why pasting a JWT into a random decoder is a credential leak

The URL-safe gotcha that breaks the browser console

The UTF-8 trap, and the emoji that proves it

Where browser-only beats the command line too

The honest limitation

Reverse-Engineering SEC EDGAR's Full-Text Search API (One Undocumented GET Request)

The endpoint and its real parameters

The two fields that unlock everything

A scraper that actually paginates

The gotchas that cost me time

Where this fits

Why Math.random() Is a Security Bug in Password Generators (and the Web Crypto Fix)

Math.random() is predictable by design

crypto.getRandomValues() is the actual fix

Gotcha 1: modulo bias is real (but size matters)

Gotcha 2: the 64KB quota wall

Why browser-only matters here

One layer is never enough

How to Compress Images From the Command Line (and in CI) — No Upload, No Account

The problem with web-based compressors in a dev workflow

Option 1: raw sharp in a script

Option 2: a tiny CLI that already does all that

Option 3: wire it into CI

A package.json shortcut

What about serverless / "I can't install native deps"?

Prefer a GUI for one-offs?

Your Online SQL Formatter Might Be Logging Your Database Password

Why "format my SQL" is a data exfiltration path

How to actually verify a tool is client-side

Where this fits in a real workflow

The structural fix

I Made an Image Compressor That Never Sees Your Images (100% Client-Side)

Why client-side matters

What it does

The tech

Try it

Why I Stopped Uploading Images to Compression Services (And Built a Browser-Only Alternative)

The Problem

The Browser Can Do This Now

What I Built

Technical Approach

When You Should Still Use Server-Side

Try It

How to Optimize Images for Website Speed in 2026 (Without Losing Quality)

Why Image Optimization Matters

The 4-Step Image Optimization Workflow

1. Choose the Right Format

2. Resize Before Compressing

3. Compress Aggressively

4. Lazy Load Everything Below the Fold

Quick Wins Checklist

Tools I Recommend

Real Results

TL;DR

TinyPNG vs QuickShrink: Why I Switched to Client-Side Image Compression

The Problem with Server-Side Compression

What is Client-Side Compression?

Comparison: TinyPNG vs QuickShrink

Compression Quality

When to Use Which

Try It

I Caught 14 Leaked Secrets in My Git History — Here is the Pre-Commit Setup That Stops It

Why Two Tools: git-secrets vs trufflehog

Setting Up git-secrets as a Pre-Commit Hook

Adding trufflehog as a Pre-Commit Hook

The Configuration Mistake That Gives False Confidence

What About GitHub’s Built-in Secret Scanning?

My Full .pre-commit-config.yaml

I Built a Free Client-Side Image Compressor (No Upload, Works Offline)

What it does

Why client-side matters

Try it

`Math.random()` is predictable by design

`crypto.getRandomValues()` is the actual fix

Option 1: raw `sharp` in a script