DEV Community: Max

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?

Why I Built a Browser-Only Image Compressor (No Uploads, No Server)

Max — Tue, 19 May 2026 17:03:03 +0000

Most image compression tools require you to upload your photos to a remote server. But what if you are compressing screenshots with sensitive data or client mockups under NDA?

The Privacy Problem

When you upload to a compression service, you trust that company to not store, not train AI on, and delete your image. You have no way to verify it.

For personal photos, acceptable risk. For business documents, medical images, legal screenshots? Real problem.

Client-Side Compression: How It Works

Modern browsers have powerful image processing APIs (Canvas API, OffscreenCanvas) that can resize and re-encode images entirely in JavaScript:

const canvas = document.createElement("canvas");
const ctx = canvas.getContext("2d");
canvas.width = img.naturalWidth;
canvas.height = img.naturalHeight;
ctx.drawImage(img, 0, 0);

// Export at reduced quality - never leaves the browser
canvas.toBlob(blob => {
  // blob is your compressed image
}, "image/jpeg", 0.8);

No fetch calls, no FormData uploads, no server round-trips.

When to Use Client-Side vs Server-Side

Client-side wins when:

Images contain confidential information
You are under NDA or HIPAA compliance
You want fastest compression (no upload wait)
Slow or metered internet connection
You value privacy

Server-side tools may be better when:

You need advanced algorithms (MozJPEG, AVIF encoding)
Batch-processing thousands of images via API
You need specific format conversions

Try It

I built QuickShrink to make this dead simple. Drop an image, get a smaller one back. No signup, no uploads, no tracking.

You can verify yourself: open DevTools Network tab and watch. Zero outbound requests during compression.

What is your approach to image optimization in your projects? Do you trust upload-based tools with sensitive content?

I built a privacy-first image compressor that runs entirely in your browser

Max — Thu, 14 May 2026 17:02:02 +0000

The Problem

Every time I needed to compress an image before deploying, I had to choose between:

Cloud tools that upload my files to unknown servers (privacy concern with client work)
CLI tools like imagemagick that require remembering flags every time
Paid tools with freemium limits that kick in at the worst moment

I just wanted something I could bookmark and use in 3 seconds.

The Solution: QuickShrink

QuickShrink is a free, browser-based image compressor. Zero uploads — all processing happens client-side using the Canvas API and modern compression algorithms.

How it works:

Drag and drop (or click to upload) any image
Adjust quality slider if needed
Download the compressed version
Your files never leave your machine

Why browser-based matters:

Privacy: No server ever sees your images. Important for NDA work, client mockups, medical images, etc.
Speed: No upload/download wait. Compression is instant for most files.
No limits: No daily caps, no signup walls, no watermarks.
Works offline: Once loaded, it works without internet.

Technical bits

The compression uses the browser Canvas API for lossy compression (JPEG quality reduction) and leverages modern browser image codecs. For PNGs, it re-encodes with optimized settings. Typical results:

4MB JPEG → ~800KB (80% reduction at quality 80)
Hero images for blogs → usually 60-70% smaller
Screenshots with text → 50-60% reduction

Who is this for?

Devs who need quick image compression before git push
Bloggers optimizing hero images
Anyone working with sensitive/client images who can not use cloud tools
People tired of signing up for yet another SaaS

Try it

👉 quickshrink.orthogonal.info

No signup. No ads. Just compression.

Feedback welcome — what features would make this more useful for your workflow?

Best TinyPNG Alternatives in 2026 (Free & Privacy-First)

Max — Thu, 07 May 2026 17:03:07 +0000

Looking for a TinyPNG alternative that's free, private, and doesn't require uploads? Here are the best options in 2026 — including one that compresses images entirely in your browser.

Why Look Beyond TinyPNG?

TinyPNG is great, but it has limitations:

Free tier limited to 20 images/month via API (500 via web)
Files are uploaded to their servers — privacy concern for sensitive images
No WebP output from the free web tool
Pro pricing starts at $25/year

If you need more flexibility, better privacy, or different output formats, these alternatives deliver.

1. QuickShrink (Best for Privacy)

Price: Free (5 images/day) | Pro $4.99/mo
Website: quickshrink.orthogonal.info

Key advantage: 100% browser-based. Your images never leave your device. Zero uploads, zero server processing.

Supports PNG, JPEG, WebP output
Adjustable quality slider
Instant results — no waiting for server response
No account required

Best for: Designers and developers who handle client assets or sensitive images and don't want them on third-party servers.

2. Squoosh (Google)

Price: Free
Website: squoosh.app

Google's open-source image compressor. Also browser-based with side-by-side preview. Excellent for single images but no batch processing.

Advanced codec options (MozJPEG, AVIF, WebP)
Real-time quality comparison
No batch mode — one image at a time

Best for: Developers who want fine-grained control over codec settings.

3. ShortPixel

Price: Free (100 images/month) | From $3.99/mo
Website: shortpixel.com

Server-based compression with WordPress plugin. Good for bulk optimization of existing sites.

WordPress integration
Lossy, glossy, and lossless modes
CDN delivery option
Files uploaded to their servers

Best for: WordPress site owners who want set-and-forget optimization.

4. Compressor.io

Price: Free (limited) | Pro $50/year
Website: compressor.io

Clean interface with good compression ratios. Supports SVG compression which most tools don't.

Supports JPEG, PNG, GIF, SVG, WebP
Up to 10MB file size
Server-side processing

Best for: Designers working with multiple formats including SVG.

5. ImageOptim (Mac Only)

Price: Free (desktop app) | API from $12/mo
Website: imageoptim.com

Desktop app that strips metadata and optimizes locally. Mac-only for the free version.

Fully offline processing
Strips EXIF data automatically
Drag-and-drop batch processing
Mac only (no Windows/Linux)

Best for: Mac users who prefer desktop workflow.

Comparison

Tool	Privacy	Batch	Free Limit	Price
QuickShrink	✅ Browser-only	Coming soon	5/day	$4.99/mo
TinyPNG	❌ Upload	✅ 20 files	500/month web	$25/yr
Squoosh	✅ Browser-only	❌	Unlimited	Free
ShortPixel	❌ Upload	✅	100/month	$3.99/mo
Compressor.io	❌ Upload	Limited	Limited	$50/yr
ImageOptim	✅ Local	✅	Unlimited	Free (Mac)

The Verdict

If privacy matters (and it should — especially with client work), QuickShrink is the strongest TinyPNG alternative. Your images stay on your device, compression happens in-browser, and it's fast.

For power users who need codec-level control, Squoosh is excellent but limited to one file at a time.

What's your go-to image compression tool? Let me know in the comments 👇

DEV Community: Max

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

Tech stack

Why I Built a Browser-Only Image Compressor (No Uploads, No Server)

The Privacy Problem

Client-Side Compression: How It Works

When to Use Client-Side vs Server-Side

Try It

I built a privacy-first image compressor that runs entirely in your browser

The Problem

The Solution: QuickShrink

How it works:

Why browser-based matters:

Technical bits

Who is this for?

Try it

Best TinyPNG Alternatives in 2026 (Free & Privacy-First)

Why Look Beyond TinyPNG?

1. QuickShrink (Best for Privacy)

2. Squoosh (Google)

`Math.random()` is predictable by design

`crypto.getRandomValues()` is the actual fix

Option 1: raw `sharp` in a script