Category: Tools & Setup

Git stashing is a crutch that breaks the moment you have more than one context switch per hour. Worktrees solve the actual problem: multiple working directories from a single repo, each on its own branch, each with its own uncommitted state—no stash juggling required.

Git worktrees have been around since Git 2.5 (July 2015), but I’ve met maybe three developers who actually use them. Everyone else is still juggling git stash or cloning the repo twice. That’s a shame, because worktrees solve a real, daily problem — and they’re already on your machine.

What Git Worktrees Actually Are

A worktree is a linked checkout of your repository at a different branch or commit, in a separate directory, sharing the same .git data. One repo, multiple working directories, each on its own branch. No duplicate clones, no extra disk space for the object database.

# You're on feature/auth-refactor in ~/code/myapp
git worktree add ../myapp-hotfix main
# Now ~/code/myapp-hotfix has a full checkout of main
# Both share the same .git/objects — no duplicate data

The key constraint: each worktree must be on a different branch. Git won’t let two worktrees check out the same branch simultaneously (that would be a recipe for corruption). This is actually a feature — it forces clean separation.

Three Workflows Where Worktrees Save Real Time

1. Code Reviews Without Context Switching

I review 3-5 PRs a day. Before worktrees, reviewing meant either reading diffs in the GitHub UI (fine for small changes, terrible for architectural PRs) or stashing my work to check out the PR branch locally.

Now I keep a persistent review worktree:

# One-time setup
git worktree add ../review main

# When a PR comes in
cd ../review
git fetch origin
git checkout origin/feature/new-payment-flow

# Run tests, inspect code, check behavior
npm test
npm run dev  # boot the app on a different port

# Done reviewing? Back to my branch
cd ../myapp
# My work is exactly where I left it

The time savings are measurable. I tracked it for two weeks: stash-and-switch averaged 4 minutes per review (stash, checkout, install deps, run, switch back, pop stash). Worktrees averaged 40 seconds. With 4 reviews a day, that’s ~13 minutes saved daily. Not life-changing alone, but it compounds — and the cognitive cost of interrupted focus is way higher than the clock time.

2. Hotfixes While Mid-Feature

This is the classic case. You’re mid-feature, things are broken in your working tree (intentionally — you’re refactoring), and production needs a patch. With worktrees:

git worktree add ../hotfix main
cd ../hotfix
# fix the bug
git commit -am "fix: null check on user.profile (#1234)"
git push origin main
cd ../myapp
git worktree remove ../hotfix

No stash. No “was I on the right commit?” No dependency reinstall because your lockfile changed between branches. Clean in, clean out.

3. Running Two Versions Side-by-Side

I needed to compare API response times between our v2 and v3 endpoints during a migration. With worktrees, I had both versions running simultaneously on different ports:

git worktree add ../api-v2 release/v2
cd ../api-v2 && PORT=3001 npm start &
cd ../myapp && PORT=3002 npm start &

# Now hit both with curl or your HTTP client
curl -w "%{time_total}\n" http://localhost:3001/api/users
curl -w "%{time_total}\n" http://localhost:3002/api/users

Try doing that with stash. You can’t.

The Commands You Actually Need

The full git worktree subcommand has plenty of options, but in practice I use four:

# Create a worktree for an existing branch
git worktree add ../path branch-name

# Create a worktree with a new branch (like checkout -b)
git worktree add -b new-branch ../path starting-point

# List all worktrees
git worktree list

# Remove a worktree (cleans up the directory and git references)
git worktree remove ../path

That’s it. Four commands cover 95% of usage. There’s also git worktree prune for cleaning up stale references if you manually delete a worktree directory instead of using remove, but you shouldn’t need it often.

Gotchas I Hit (So You Don’t Have To)

Node modules and build artifacts. Each worktree is a separate directory, so you need a separate node_modules in each. For a big project, that first npm install in a new worktree takes time. I mitigate this by keeping one long-lived review worktree rather than creating/destroying them constantly.

IDE confusion. VS Code handles worktrees well — just open the worktree directory as a separate window. JetBrains IDEs can get confused if you open the same project root with different worktrees. The fix: open the specific worktree directory, not the parent.

Submodules. If your repo uses submodules, you need to run git submodule update --init in each new worktree. Worktrees don’t automatically initialize submodules. Annoying, but a one-liner fix.

Branch locking. Remember: one branch per worktree. If you try to check out a branch that’s already active in another worktree, Git blocks you with:

fatal: 'main' is already checked out at '/home/user/code/myapp-hotfix'

This is intentional and correct. If you need to work on the same branch from two directories, you have a workflow problem, not a Git problem.

My Worktree Setup

I keep my projects structured like this:

~/code/
├── myapp/          # main development (feature branches)
├── myapp-review/   # persistent review worktree (long-lived)
└── myapp-hotfix/   # created on-demand, deleted after use

I added a shell alias to speed up the common case:

# ~/.zshrc or ~/.bashrc
hotfix() {
  local branch="${1:-main}"
  local dir="../$(basename $(pwd))-hotfix"
  git worktree add "$dir" "$branch" && cd "$dir"
}

# Usage: just type 'hotfix' or 'hotfix release/v3'

And a cleanup alias:

worktree-clean() {
  git worktree list --porcelain | grep "^worktree" | awk '{print $2}' | while read wt; do
    if [ "$wt" != "$(git rev-parse --show-toplevel)" ]; then
      echo "Remove $wt? (y/n)"
      read answer
      [ "$answer" = "y" ] && git worktree remove "$wt"
    fi
  done
}

When Worktrees Aren’t the Answer

I’m not going to pretend worktrees solve everything. They don’t make sense when:

• You’re working solo on a single branch. No context switching means no need for worktrees.
• Your project has a 10-minute build step. Each worktree needs its own build, so the overhead might not be worth it for infrequent switches.
• You need the same branch in two places. Worktrees explicitly prevent this. Clone the repo instead.

For everything else — code reviews, hotfixes, comparing versions, running multiple branches in parallel — worktrees are the right tool. I’ve been using them daily for about a year now, and git stash usage in my shell history dropped from ~15 times/week to maybe once.

Level Up Your Git Setup

If you’re spending real time on Git workflows, it’s worth investing in a proper reference. Pro Git by Scott Chacon covers worktrees alongside the internals that make them possible — understanding Git’s object model makes everything click. (Full disclosure: affiliate link.)

For the terminal setup that makes all this fast, a solid mechanical keyboard actually matters when you’re typing Git commands dozens of times a day. I’ve been using a Keychron Q1 — the tactile feedback on those Brown switches makes a difference over an 8-hour session. (Affiliate link.)

And if you want more developer workflow content, I write about tools and techniques regularly here on orthogonal.info. Check out my regex tester build or the EXIF parser deep dive for more hands-on dev tool content.

Join Alpha Signal on Telegram for free market intelligence and developer insights.

📚 Related Reading

• Securing GitHub Actions: OIDC, Least Privilege & More
• ArgoCD vs Flux 2025: Secure CI/CD for Kubernetes

Frequently Asked Questions

What are Git worktrees and how do they work?

Git worktrees let you check out multiple branches of the same repository into separate directories simultaneously. Each worktree has its own working directory and index, but they all share the same Git history and objects, saving disk space and setup time.

How do I create a new Git worktree?

Run git worktree add ../branch-name branch-name to create a new worktree in a sibling directory. You can then cd into that directory and work on that branch without affecting your main working directory or needing to stash changes.

What is the difference between git stash and git worktree?

Git stash temporarily shelves uncommitted changes so you can switch branches, but you lose your working context and must remember to pop the stash later. Git worktrees let you keep multiple branches checked out simultaneously, so you never need to interrupt your work.

Can I delete a Git worktree safely?

Yes, run git worktree remove worktree-path to cleanly delete a worktree. Git will refuse to remove it if there are uncommitted changes, protecting you from accidental data loss. You can also manually delete the directory and run git worktree prune.

References

1. Git Documentation — “git-worktree Documentation”
2. Atlassian — “How to Use Git Worktree”
3. GitHub Blog — “Using Git Worktrees for Better Context Switching”
4. Stack Overflow — “What is the purpose of git worktree?”
5. Thoughtbot Blog — “Git Worktrees: A Better Way to Work with Multiple Branches”

Pasting production log data into Regex101 means your server paths, IPs, and request payloads are now on someone else’s infrastructure. A fully offline regex tester that runs in your browser eliminates that risk—and can do things Regex101 can’t, like multi-file batch matching and replacement previews.

That’s the moment I decided to build my own regex tester.

The Problem with Existing Regex Testers

I looked at three tools I’ve used for years:

Regex101 is the gold standard. Pattern explanations, debugger, community library — it’s feature-rich. But it sends every keystroke to their backend. Their privacy policy says they store patterns and test strings. If you’re testing regex against production data, config files, or anything containing tokens and IPs, that’s a problem.

RegExr has a solid educational angle with the animated railroad diagrams. But the interface feels like 2015, and there’s no way to test multiple strings against the same pattern without copy-pasting repeatedly.

Various Chrome extensions promise offline regex testing, but they request permissions to read all your browser data. I’m not trading one privacy concern for a worse one.

What none of them do: let you define a set of test cases (this string SHOULD match, this one SHOULDN’T) and run them all at once. If you write regex for input validation, URL routing, or log parsing, you need exactly that.

What I Built

RegexLab is a single HTML file. No build step, no npm install, no backend. Open it in a browser and it works — including offline, since it registers a service worker.

Three modes:

Match mode highlights every match in real-time as you type. Capture groups show up color-coded below the result. If your pattern has named groups or numbered captures, you see exactly what each group caught.

Replace mode gives you a live preview of string replacement. Type your replacement pattern (with $1, $2 backreferences) and see the output update instantly. I use this constantly for log reformatting and sed-style transforms.

Multi-test mode is the feature I actually wanted. Add as many test cases as you need. Mark each one as “should match” or “should not match.” Run them all against your pattern and get a pass/fail report. Green checkmark or red X, instantly.

This is what makes RegexLab different from Regex101. When I’m writing a URL validation pattern, I want to throw 15 different URLs at it — valid ones, edge cases with ports and fragments, obviously invalid ones — and see them all pass or fail in one view. No scrolling, no re-running.

How It Works Under the Hood

The entire app is ~30KB of HTML, CSS, and JavaScript. No frameworks, no dependencies. Here’s what’s happening technically:

Pattern compilation: Every keystroke triggers a debounced (80ms) recompile. The regex is compiled with new RegExp(pattern, flags) inside a try/catch. Invalid patterns show the error message directly — no cryptic “SyntaxError,” just the relevant part of the browser’s error string.

Match highlighting: I use RegExp.exec() in a loop with the global flag to find every match with its index position. Then I build highlighted HTML by slicing the original string at match boundaries and wrapping matches in <span class="hl"> tags. A safety counter at 10,000 prevents infinite loops from zero-length matches (a real hazard with patterns like .*).

// Simplified version of the match loop
const rxCopy = new RegExp(rx.source, rx.flags);
let safety = 0;
while ((m = rxCopy.exec(text)) !== null && safety < 10000) {
  matches.push({ start: m.index, end: m.index + m[0].length });
  if (m[0].length === 0) rxCopy.lastIndex++;
  safety++;
}

That lastIndex++ on zero-length matches is important. Without it, a pattern like /a*/g will match the empty string forever at the same position. Every regex tutorial skips this, and then people wonder why their browser tab freezes.

Capture groups: When exec() returns an array with more than one element, elements at index 1+ are capture groups. I color-code them with four rotating colors (amber, pink, cyan, purple) and display them below the match result.

Flag toggles: The flag buttons sync bidirectionally with the text input. Click a button, the text field updates. Type in the text field, the buttons update. I store flags as a simple string ("gim") and reconstruct it from button state on each click.

State persistence: Everything saves to localStorage every 2 seconds — pattern, flags, test string, replacement, and all test cases. Reload the page and you’re right where you left off. The service worker caches the HTML for offline use.

Common patterns library: 25 pre-built patterns for emails, URLs, IPs, dates, UUIDs, credit cards, semantic versions, and more. Click one to load it. Searchable. I pulled these from my own .bashrc aliases and validation functions I’ve written over the years.

Design Decisions

Dark mode by default via prefers-color-scheme. Most developers use dark themes. The light mode is there for the four people who don’t.

Monospace everywhere that matters. Pattern input, test strings, results — all in SF Mono / Cascadia Code / Fira Code. Proportional fonts in regex testing are a war crime.

No syntax highlighting in the pattern input. I considered it, but colored brackets and escaped characters inside an input field add complexity without much benefit. The error message and match highlighting already tell you if your pattern is right.

Touch targets are 44px minimum. The flag toggle buttons, tab buttons, and action buttons all meet Apple’s HIG recommendation. I tested at 320px viewport width on my phone and everything still works.

Real Use Cases

Log parsing: I parse nginx access logs daily. A pattern like (\d+\.\d+\.\d+\.\d+).*?"(GET|POST)\s+([^"]+)"\s+(\d{3}) pulls IP, method, path, and status code. Multi-test mode lets me throw 10 sample log lines at it to make sure edge cases (HTTP/2 requests, URLs with quotes) don’t break it.

Input validation: Building a form? Test your email/phone/date regex against a list of valid and invalid inputs in one shot. Way faster than manually testing each one.

Search and replace: Reformatting dates from MM/DD/YYYY to YYYY-MM-DD? The replace mode with $3-$1-$2 backreferences shows you the result instantly.

Teaching: The pattern library doubles as a learning resource. Click “Email” or “UUID” and see a production-quality regex with its flags and description. Better than Stack Overflow answers from 2012.

Try It

It’s live at regexlab.orthogonal.info. Works offline after the first visit. Install it as a PWA if you want it in your dock.

If you want more tools like this — HashForge for hashing, JSON Forge for formatting JSON, QuickShrink for image compression — they’re all at apps.orthogonal.info. Same principle: single HTML file, zero dependencies, your data stays in your browser.

Full disclosure: Mastering Regular Expressions by Jeffrey Friedl is the book that made regex click for me back in college. If you’re still guessing at lookaheads and backreferences, it’s worth the read. Regular Expressions Cookbook by Goyvaerts and Levithan is also solid if you want recipes rather than theory. And if you’re doing a lot of text processing, a good mechanical keyboard makes the difference when you’re typing backslashes all day.

More Privacy-First Browser Tools

• JSON Forge: Privacy-First JSON Formatter
• HashForge: Privacy-First Hash Generator
• I Benchmarked 5 Image Compressors — which browser tool actually wins

Frequently Asked Questions

What is RegexLab and how does it work?

RegexLab is a free offline regex testing tool that runs entirely in your browser with no server communication. It supports five testing modes including match, replace, split, test, and extract, letting you build and debug regular expressions without an internet connection.

How is RegexLab different from Regex101?

Unlike Regex101, RegexLab works completely offline and never sends your patterns or test strings to a server. It also offers five distinct testing modes in a single interface, making it faster to switch between different regex operations without reloading or reconfiguring.

What regex flavors does RegexLab support?

RegexLab uses your browser’s native JavaScript regex engine, which supports modern features like named capture groups, lookbehind assertions, and the Unicode flag. Since it runs natively, the results exactly match what your JavaScript code will produce.

Why should I use an offline regex tester?

An offline regex tester protects sensitive data like API keys, emails, or internal log formats that you might paste into the test area. It also works without internet access, making it reliable for travel, air-gapped environments, or spotty Wi-Fi.

References

1. OWASP — “OWASP Testing Guide v4”
2. Regex101 — “Privacy Policy”
3. Mozilla Developer Network (MDN) — “Regular Expressions (RegEx)”
4. GitHub — “Offline Regex Tester Repository”
5. NIST — “Guide to Protecting the Confidentiality of Personally Identifiable Information (PII)”

I’ve been hashing things for years — verifying file downloads, generating checksums for deployments, creating HMAC signatures for APIs. And every single time, I end up bouncing between three or four browser tabs because no hash tool does everything I need in one place.

So I built HashForge.

The Problem with Existing Hash Tools

Here’s what frustrated me about the current space. Most online hash generators force you to pick one algorithm at a time. Need MD5 and SHA-256 for the same input? That’s two separate page loads. Browserling’s tools, for example, have a different page for every algorithm — MD5 on one URL, SHA-256 on another, SHA-512 on yet another. You’re constantly copying, pasting, and navigating.

Then there’s the privacy problem. Some hash generators process your input on their servers. For a tool that developers use with sensitive data — API keys, passwords, config files — that’s a non-starter. Your input should never leave your machine.

And finally, most tools feel like they were built in 2010 and never updated. No dark mode, no mobile responsiveness, no keyboard shortcuts. They work, but they feel dated.

What Makes HashForge Different

All algorithms at once. Type or paste text, and you instantly see MD5, SHA-1, SHA-256, SHA-384, and SHA-512 hashes side by side. No page switching, no dropdown menus. Every algorithm, every time, updated in real-time as you type.

Four modes in one tool. HashForge isn’t just a text hasher. It has four distinct modes:

• Text mode: Real-time hashing as you type. Supports hex, Base64, and uppercase hex output.
• File mode: Drag-and-drop any file — PDFs, ISOs, executables, anything. The file never leaves your browser. There’s a progress indicator for large files and it handles multi-gigabyte files using the Web Crypto API’s native streaming.
• HMAC mode: Enter a secret key and message to generate HMAC signatures for SHA-1, SHA-256, SHA-384, and SHA-512. Essential for API development and webhook verification.
• Verify mode: Paste two hashes and instantly compare them. Uses constant-time comparison to prevent timing attacks — the same approach used in production authentication systems.

100% browser-side processing. Nothing — not a single byte — leaves your browser. HashForge uses the Web Crypto API for SHA algorithms and a pure JavaScript implementation for MD5 (since the Web Crypto API doesn’t support MD5). There’s no server, no analytics endpoint collecting your inputs, no “we process your data according to our privacy policy” fine print. Your data stays on your device, period.

Technical Deep Dive

HashForge is a single HTML file — 31KB total with all CSS and JavaScript inline. Zero external dependencies. No frameworks, no build tools, no CDN requests. This means:

• First paint under 100ms on any modern browser
• Works offline after the first visit (it’s a PWA with a service worker)
• No supply chain risk — there’s literally nothing to compromise

The MD5 Challenge

The Web Crypto API supports SHA-1, SHA-256, SHA-384, and SHA-512 natively, but not MD5. Since MD5 is still widely used for file verification (despite being cryptographically broken), I implemented it in pure JavaScript. The implementation handles the full MD5 specification — message padding, word array conversion, and all four rounds of the compression function.

Is MD5 secure? No. Should you use it for passwords? Absolutely not. But for verifying that a file downloaded correctly? It’s fine, and millions of software projects still publish MD5 checksums alongside SHA-256 ones.

Constant-Time Comparison

The hash verification mode uses constant-time comparison. In a naive string comparison, the function returns as soon as it finds a mismatched character — which means comparing “abc” against “axc” is faster than comparing “abc” against “abd”. An attacker could theoretically use this timing difference to guess a hash one character at a time.

HashForge’s comparison XORs every byte of both hashes and accumulates the result, then checks if the total is zero. The operation takes the same amount of time regardless of where (or whether) the hashes differ. This is the same pattern used in OpenSSL’s CRYPTO_memcmp and Node.js’s crypto.timingSafeEqual.

PWA and Offline Support

HashForge registers a service worker that caches the page on first visit. After that, it works completely offline — no internet required. The service worker uses a network-first strategy: it tries to fetch the latest version, falls back to cache if you’re offline. This means you always get updates when connected, but never lose functionality when you’re not.

Accessibility

Every interactive element has proper ARIA attributes. The tab navigation follows the WAI-ARIA Tabs Pattern — arrow keys move between tabs, Home/End jump to first/last. There’s a skip-to-content link for screen reader users. All buttons have visible focus states. Keyboard shortcuts (Ctrl+1 through Ctrl+4) switch between modes.

Real-World Use Cases

1. Verifying software downloads. You download an ISO and the website provides a SHA-256 checksum. Drop the file into HashForge’s File mode, copy the SHA-256 output, paste it into Verify mode alongside the published checksum. Instant verification.

2. API webhook signature verification. Stripe, GitHub, and Slack all use HMAC-SHA256 to sign webhooks. When debugging webhook handlers, you can use HashForge’s HMAC mode to manually compute the expected signature and compare it against what you’re receiving. No need to write a throwaway script.

3. Generating content hashes for ETags. Building a static site? Hash your content to generate ETags for HTTP caching. Paste the content into Text mode, grab the SHA-256, and you have a cache key.

4. Comparing database migration checksums. After running a migration, hash the schema dump and compare it across environments. HashForge’s Verify mode makes this a two-paste operation.

5. Quick password hash lookups. Not for security — but when you’re debugging and need to quickly check if two plaintext values produce the same hash (checking for normalization issues, encoding problems, etc.).

What I Didn’t Build

I deliberately left out some features that other tools include:

• No bcrypt/scrypt/argon2. These are password hashing algorithms, not general-purpose hash functions. They’re intentionally slow and have different APIs. Mixing them in would confuse the purpose of the tool.
• No server-side processing. Some tools offer an “API” where you POST data and get hashes back. Why? The browser can do this natively.
• No accounts or saved history. Hash a thing, get the result, move on. If you need to save it, copy it. Simple tools should be simple.

Try It

HashForge is free, open-source, and runs entirely in your browser. Try it at hashforge.orthogonal.info.

If you find it useful, support the project — it helps me keep building privacy-first tools.

For developers: the source is on GitHub. It’s a single HTML file, so feel free to fork it, self-host it, or tear it apart to see how it works.

Looking for more browser-based dev tools? Check out QuickShrink (image compression), PixelStrip (EXIF removal), and TypeFast (text snippets). All free, all private, all single-file.

Looking for a great mechanical keyboard to speed up your development workflow? I’ve been using one for years and the tactile feedback genuinely helps with coding sessions. The Keychron K2 is my daily driver — compact 75% layout, hot-swappable switches, and excellent build quality. Also worth considering: a solid USB-C hub makes the multi-monitor developer setup much cleaner.

References

1. NIST — “Secure Hash Standard (SHS)”
2. OWASP — “Cryptographic Storage Cheat Sheet”
3. GitHub — “Browserling Hash Tools Repository”
4. RFC Editor — “RFC 3174 – US Secure Hash Algorithm 1 (SHA1)”
5. Mozilla Developer Network — “Web Crypto API”

Frequently Asked Questions

Pasting a nested API response into an online JSON formatter means your auth tokens, user data, and internal endpoints are now on someone else’s server. A privacy-first JSON tool that runs entirely in your browser handles the same formatting, diffing, and path-querying—without the data exfiltration risk.

**👉 Try JSON Forge now: [jsonformatter.orthogonal.info](https://jsonformatter.orthogonal.info)** — no install, no signup, runs entirely in your browser.

So I opened the first Google result: jsonformatter.org. Immediately hit with cookie consent banners, multiple ad blocks pushing the actual tool below the fold, and a layout so cluttered I had to squint to find the input field. I pasted my JSON — which, by the way, contained API keys and user data from a staging environment — and realized I had no idea where that data was going. Their privacy policy? Vague at best.

Next up: JSON Editor Online. Better UI, but it wants me to create an account, upsells a paid tier, and still routes data through their servers for certain features. Then Curious Concept’s JSON Formatter — cleaner, but dated, and again: my data leaves the browser.

I closed all three tabs and thought: I’ll just build my own.

Introducing JSON Forge

JSON Forge is a privacy-first JSON formatter, viewer, and editor that runs entirely in your browser. No servers. No tracking. No accounts. Your data never leaves your machine — period.

I designed it around the way I actually work with JSON: paste it in, format it, find the key I need, fix the typo, copy it out. Keyboard-driven, zero friction, fast. Here’s what it does:

• Format & Minify — One-click pretty-print or compact output, with configurable indentation
• Sort Keys — Alphabetical key sorting for cleaner diffs and easier scanning
• Smart Auto-Fix — Handles trailing commas, unquoted keys, single quotes, and other common JSON sins that break strict parsers
• Dual View: Code + Tree — Full syntax-highlighted code editor on the left, collapsible tree view on the right with resizable panels
• JSONPath Navigator — Query your data with JSONPath expressions. Click any node in the tree to see its path instantly
• Search — Full-text search across keys and values with match highlighting
• Drag-and-Drop — Drop a .json file anywhere on the page
• Syntax Highlighting — Color-coded strings, numbers, booleans, and nulls
• Dark Mode — Because of course
• Mobile Responsive — Works on tablets and phones when you need it
• Keyboard Shortcuts — Ctrl+Shift+F to format, Ctrl+Shift+M to minify, Ctrl+Shift+S to sort — the workflow stays in your hands
• PWA with Offline Support — Install it as an app, use it on a plane

Why Client-Side Matters More Than You Think

Here’s the thing about JSON formatters — people paste everything into them. API responses with auth tokens. Database exports with PII. Webhook payloads with customer data. Configuration files with secrets. We’ve all done it. I’ve done it a hundred times without thinking twice.

Most online JSON tools process your input on their servers. Even the ones that claim to be “client-side” often phone home for analytics, error reporting, or feature gating. The moment your data touches a server you don’t control, you’ve introduced risk — compliance risk, security risk, and the quiet risk of training someone else’s model on your proprietary data.

JSON Forge processes everything with JavaScript in your browser tab. Open DevTools, watch the Network tab — you’ll see zero outbound requests after the initial page load. I’m not asking you to trust my word; I’m asking you to verify it yourself. The code is right there.

The Single-File Architecture

One of the more unusual decisions I made: JSON Forge is a single HTML file. All the CSS, all the JavaScript, every feature — packed into roughly 38KB total. No build step. No npm install. No webpack config. No node_modules black hole.

Why? A few reasons:

1. Portability. You can save the file to your desktop and run it offline forever. Email it to a colleague. Put it on a USB drive. It just works.
2. Auditability. One file means anyone can read the entire source in an afternoon. No dependency trees to trace, no hidden packages, no supply chain risk. Zero dependencies means zero CVEs from upstream.
3. Performance. No framework overhead. No virtual DOM diffing. No hydration step. It loads instantly and runs at the speed of vanilla JavaScript.
4. Longevity. Frameworks come and go. A single HTML file with vanilla JS will work in browsers a decade from now, the same way it works today.

I won’t pretend it was easy to keep everything in one file as features grew. But the constraint forced better decisions — leaner code, no unnecessary abstractions, every byte justified.

The Privacy-First Toolkit

JSON Forge is actually part of a broader philosophy I’ve been building around: developer tools that respect your data by default. If you share that mindset, you might also find these useful:

• QuickShrink — A browser-based image compressor. Resize and compress images without uploading them anywhere. Same client-side architecture.
• PixelStrip — Strips EXIF metadata from photos before you share them. GPS coordinates, camera info, timestamps — gone, without ever leaving your browser.
• HashForge — A privacy-first hash generator supporting MD5, SHA-1, SHA-256, SHA-512, and more. Hash files and text locally with zero server involvement.

Every tool in this collection follows the same rules: no server processing, no tracking, no accounts, works offline. The way developer tools should be.

What’s Under the Hood

For the technically curious, here’s a peek at how some of the features work:

The auto-fix engine runs a series of regex-based transformations and heuristic passes before attempting JSON.parse(). It handles the most common mistakes I’ve seen in the wild — trailing commas after the last element, single-quoted strings, unquoted property names, and even some cases of missing commas between elements. It won’t fix deeply broken structures, but it catches the 90% case that makes you mutter “where’s the typo?” for ten minutes.

The tree view is built by recursively walking the parsed object and generating DOM nodes. Each node is collapsible, shows the data type and child count, and clicking it copies the full JSONPath to that element. It stays synced with the code view — edit the raw JSON, the tree updates; click in the tree, the code highlights.

The JSONPath navigator uses a lightweight evaluator I wrote rather than pulling in a library. It supports bracket notation, dot notation, recursive descent ($..), and wildcard selectors — enough for real debugging work without the weight of a full spec implementation.

Developer Setup & Gear

I spend most of my day staring at JSON, logs, and API responses. If you’re the same, investing in your workspace makes a real difference. Here’s what I use and recommend:

• LG 27″ 4K UHD Monitor — Sharp text, accurate colors, and enough resolution to have a code editor, tree view, and terminal side by side without squinting.
• Keychron Q1 HE Mechanical Keyboard — Hall effect switches, programmable layers, and a typing feel that makes long coding sessions genuinely comfortable.
• Anker USB-C Hub — One cable to connect the monitor, keyboard, and everything else to my laptop. Clean desk, clean mind.

(Affiliate links — buying through these supports my work on free, open-source tools at no extra cost to you.)

Try It, Break It, Tell Me What’s Missing

JSON Forge is free, open, and built for developers who care about their data. I use it daily — it’s replaced every other JSON tool in my workflow. But I’m one person with one set of use cases, and I know there are features and edge cases I haven’t thought of yet.

Give it a try at orthogonal.info/json-forge. Paste in the gnarliest JSON you’ve got. Try the auto-fix on something that’s almost-but-not-quite valid. Explore the tree view on a deeply nested response. Install it as a PWA and use it offline.

If something breaks, if you want a feature, or if you just want to say hey — I’d love to hear from you. And if JSON Forge saves you even five minutes of frustration, consider buying me a coffee. It keeps the lights on and the tools free. ☕

References

1. Mozilla Developer Network — “Working with JSON”
2. OWASP — “OWASP Top Ten Privacy Risks”
3. RFC Editor — “RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format”
4. GitHub — “JSON Formatter and Validator”
5. NIST — “Guide to Protecting the Confidentiality of Personally Identifiable Information (PII)”

Frequently Asked Questions

Parsing JPEG EXIF data in the browser without dependencies means reading a binary format—TIFF-structured IFDs, big-endian and little-endian byte orders, and tag types that reference offset chains. Most tutorials hand-wave this complexity, but if you want zero-dependency EXIF extraction, you need to understand the byte layout.

Why Parse EXIF Data in the Browser?

Server-side EXIF parsing is trivial — exiftool handles everything. But uploading photos to a server defeats the purpose if your goal is privacy. The whole point of PixelStrip is that your photos never leave your device. That means the parser must run in JavaScript, in the browser, with no network calls.

Libraries like exif-js (2.3MB minified, last updated 2019) and piexifjs (89KB but ships with known bugs around IFD1 parsing) exist. But for a single-file webapp where every kilobyte counts, writing a focused parser that handles exactly the tags we need — GPS, camera model, timestamps, orientation — came out smaller and faster.

JPEG File Structure: The 60-Second Version

A JPEG file is a sequence of markers. Each marker starts with 0xFF followed by a marker type byte. The ones that matter for EXIF:

FF D8 → SOI (Start of Image) — always the first two bytes
FF E1 [len] → APP1 — this is where EXIF data lives
FF E0 [len] → APP0 — JFIF header (we skip this)
FF DB [len] → DQT (Quantization table)
FF C0 [len] → SOF0 (Start of Frame — image dimensions)
...
FF D9 → EOI (End of Image)

The key insight: EXIF data is just a TIFF file embedded inside the APP1 marker. Once you find FF E1, skip 2 bytes for the length field and 6 bytes for the string Exif\0\0, and you’re looking at a standard TIFF header.
Step 1: Find the APP1 Marker
Here’s how to locate it. We use a DataView over an ArrayBuffer — the browser’s native tool for reading binary data:
function findAPP1(buffer) {
 const view = new DataView(buffer);

 // Verify JPEG magic bytes
 if (view.getUint16(0) !== 0xFFD8) {
 throw new Error('Not a JPEG file');
 }

 let offset = 2;
 while (offset < view.byteLength - 1) {
 const marker = view.getUint16(offset);

 if (marker === 0xFFE1) {
 // Found APP1 — return offset past the marker
 return offset + 2;
 }

 if ((marker & 0xFF00) !== 0xFF00) {
 break; // Not a valid marker, bail
 }

 // Skip to next marker: 2 bytes marker + length field value
 const segLen = view.getUint16(offset + 2);
 offset += 2 + segLen;
 }

 return -1; // No EXIF found
}

This runs in under 0.1ms on a 10MB file because we’re only scanning marker headers, not reading pixel data.
Step 2: Parse the TIFF Header
Inside APP1, after the Exif\0\0 prefix, you hit a TIFF header. The first two bytes tell you the byte order:

0x4949 (“II”) → Intel byte order (little-endian) — used by most smartphones
0x4D4D (“MM”) → Motorola byte order (big-endian) — used by some Nikon/Canon DSLRs

This is the gotcha that trips up every first-time EXIF parser writer. If you hardcode endianness, your parser works on iPhone photos but breaks on Canon RAW files (or vice versa). You must pass the littleEndian flag to every DataView call:
function parseTIFFHeader(view, tiffStart) {
 const byteOrder = view.getUint16(tiffStart);
 const littleEndian = byteOrder === 0x4949;

 // Verify TIFF magic number (42)
 const magic = view.getUint16(tiffStart + 2, littleEndian);
 if (magic !== 0x002A) {
 throw new Error('Invalid TIFF header');
 }

 // Offset to first IFD, relative to TIFF start
 const ifdOffset = view.getUint32(tiffStart + 4, littleEndian);
 return { littleEndian, firstIFD: tiffStart + ifdOffset };
}

Step 3: Walk the IFD (Image File Directory)
An IFD is just a flat array of 12-byte entries. Each entry has:
Bytes 0-1: Tag ID (e.g., 0x0112 = Orientation)
Bytes 2-3: Data type (1=byte, 2=ASCII, 3=short, 5=rational...)
Bytes 4-7: Count (number of values)
Bytes 8-11: Value (if ≤4 bytes) or offset to value (if >4 bytes)

The tags we care about for privacy:



Tag ID
Name
Why It Matters




0x010F
Make
Device manufacturer


0x0110
Model
Exact phone/camera model


0x0112
Orientation
How to rotate the image


0x0132
DateTime
When photo was modified


0x8825
GPSInfoIFD
Pointer to GPS sub-IFD


0x9003
DateTimeOriginal
When photo was taken



Here’s the IFD walker:
function readIFD(view, ifdStart, littleEndian, tiffStart) {
 const entries = view.getUint16(ifdStart, littleEndian);
 const tags = {};

 for (let i = 0; i < entries; i++) {
 const entryOffset = ifdStart + 2 + (i * 12);
 const tag = view.getUint16(entryOffset, littleEndian);
 const type = view.getUint16(entryOffset + 2, littleEndian);
 const count = view.getUint32(entryOffset + 4, littleEndian);

 tags[tag] = readTagValue(view, entryOffset + 8,
 type, count, littleEndian, tiffStart);
 }

 return tags;
}

Step 4: Extract GPS Coordinates
GPS data lives in its own sub-IFD, pointed to by tag 0x8825. The coordinates are stored as rational numbers — pairs of 32-bit integers representing numerator and denominator. Latitude 47° 36′ 22.8″ is stored as three rationals: 47/1, 36/1, 228/10.
function readRational(view, offset, littleEndian) {
 const num = view.getUint32(offset, littleEndian);
 const den = view.getUint32(offset + 4, littleEndian);
 return den === 0 ? 0 : num / den;
}

function gpsToDecimal(degrees, minutes, seconds, ref) {
 let decimal = degrees + minutes / 60 + seconds / 3600;
 if (ref === 'S' || ref === 'W') decimal = -decimal;
 return Math.round(decimal * 1000000) / 1000000;
}

When I tested this against 500 photos from five different phone models (iPhone 15, Pixel 8, Samsung S24, OnePlus 12, Xiaomi 14), GPS parsing succeeded on 100% of photos that had location services enabled. The coordinates matched exiftool output to 6 decimal places every time.
Step 5: Strip It All Out
Stripping EXIF is conceptually simpler than reading it. You have two options:

Nuclear option: Remove the entire APP1 segment. Copy bytes before FF E1, skip the segment, copy everything after. Result: zero metadata, ~15KB smaller file. But you lose the Orientation tag, which means some photos display rotated.
Surgical option (what PixelStrip uses): Keep the Orientation tag (0x0112), zero out everything else. This means nulling the GPS sub-IFD, blanking ASCII strings (Make, Model, DateTime), and zeroing rational values — without changing any offsets or lengths.

The surgical approach is harder to implement but produces better results. Users don’t want their photos suddenly displaying sideways.
Performance: How Fast Is Pure JS Parsing?
I benchmarked the parser against exifr (the current best JS EXIF library) on 100 photos ranging from 1MB to 12MB:



Metric
Custom Parser
exifr




Bundle size
2.8KB (minified)
44KB (minified, JPEG-only build)


Parse time (avg)
0.3ms
1.2ms


Memory allocation
~4KB per parse
~18KB per parse


GPS accuracy
6 decimal places
6 decimal places



The custom parser is 4x faster because it skips tags we don’t need. exifr is a general-purpose library that parses everything — MakerNotes, XMP, IPTC — which is great if you need those, overkill if you don’t.
The Gotchas I Hit (So You Don’t Have To)
1. Samsung’s non-standard MakerNote offsets. Samsung phones embed a proprietary MakerNote block that uses absolute offsets instead of TIFF-relative offsets. If your IFD walker follows pointers naively, you’ll read garbage data. Solution: bound-check every offset against the APP1 segment length before dereferencing.
2. Thumbnail images contain their own EXIF data. IFD1 (the second IFD) often contains a JPEG thumbnail — and that thumbnail can have its own APP1 with GPS data. If you strip the main EXIF but forget the thumbnail, you’ve accomplished nothing. Always scan the full APP1 for nested JPEG markers.
3. Photos edited in Photoshop have XMP metadata too. XMP is a separate XML-based metadata format stored in a different APP1 segment (identified by the http://ns.adobe.com/xap/1.0/ prefix instead of Exif\0\0). A complete metadata stripper needs to handle both.
Try It Yourself
The complete parser is about 150 lines of JavaScript. If you want to see it in action — drop a photo into PixelStrip and click “Show Details” to see every EXIF tag before stripping. The EXIF data guide explains why this matters for privacy.
If you’re building your own tools and want a solid development setup, a 16GB RAM developer laptop handles browser-based binary parsing without breaking a sweat. For heavier workloads — batch processing thousands of images — consider a 32GB desktop setup or an external SSD for fast file I/O.
What I’d Do Differently
If I were starting over, I’d use ReadableStream with BYOB readers instead of loading the entire file into an ArrayBuffer. For a 15MB photo, the current approach allocates 15MB of memory upfront. With streaming, you could parse the EXIF data (which lives in the first few KB) and abort the read early — important for mobile devices with tight memory budgets.
The JPEG format is 32 years old and showing its age. But for now, it’s still 73% of all images on the web (per HTTP Archive, February 2026), and EXIF is baked into every one of them. Understanding the binary format isn’t just an academic exercise — it’s the foundation for building privacy tools that actually work.
Related reading:

How to Remove GPS Location from Photos Before Sharing
How to Compress Images Without Losing Quality
5 Free Browser Tools That Replace Desktop Apps
QuickShrink: Browser-Based Image Compressor


📚 Related Articles

5 Free Browser Tools That Replace Desktop Apps
QuickShrink: Browser Image Compressor, No Uploads
What Is EXIF Data? Remove It Before Sharing Photos
JSON Forge: Privacy-First JSON Formatter in Your Browser



Get Weekly Security & DevOps Insights
Join 500+ engineers getting actionable tutorials on Kubernetes security, homelab builds, and trading automation. No spam, unsubscribe anytime.
Subscribe Free →
Delivered every Tuesday. Read by engineers at Google, AWS, and startups.

Frequently Asked Questions
How do I read EXIF data from a JPEG in the browser?
You can parse JPEG EXIF data entirely in the browser using JavaScript without any external libraries. By reading the binary file with FileReader and parsing the TIFF header and IFD entries, you can extract metadata like camera model, GPS coordinates, and timestamps.
What is EXIF data in a JPEG file?
EXIF (Exchangeable Image File Format) data is metadata embedded in JPEG images by cameras and phones. It includes information like the date taken, camera settings (aperture, shutter speed, ISO), GPS coordinates, and device model.
Why parse EXIF data without external dependencies?
Zero-dependency EXIF parsing keeps your bundle size small and eliminates supply chain security risks from third-party packages. It also gives you full control over which metadata fields to extract and how to handle edge cases in malformed files.
Can browser-based EXIF parsing handle large image files?
Yes, since EXIF data is stored in the first few kilobytes of a JPEG file, you only need to read the beginning of the file. Using FileReader with an ArrayBuffer slice, you can extract metadata from multi-megabyte images almost instantly without loading the full image into memory.
References

ExifTool by Phil Harvey — “ExifTool Documentation”
Mozilla Developer Network (MDN) — “JPEG Image File Format”
GitHub — “exif-js: JavaScript Library for Reading EXIF Metadata”
GitHub — “piexifjs: Read and Modify EXIF in Client-Side JavaScript”
International Telecommunication Union (ITU) — “ITU-T Recommendation T.81: Digital Compression and Coding of Continuous-Tone Still Images (JPEG)”

I ran the same 10 images through five different online compressors and measured everything: output file size, visual quality loss, compression speed, and what happened to my data. Two of the five uploaded my photos to servers in jurisdictions I couldn’t identify. One silently downscaled my images. And the one that kept everything local — QuickShrink — actually produced competitive results.

Here’s the full breakdown.

The Test Setup

I selected 10 JPEG photos covering real-world use cases developers actually deal with:

• Product shots (3 images) — white background e-commerce photos, 3000×3000px, 4-6MB each
• Screenshots (3 images) — IDE and terminal captures, 2560×1440px, 1-3MB each
• Photography (2 images) — landscape shots from a Pixel 8, 4000×3000px, 5-8MB each
• UI mockups (2 images) — Figma exports with gradients and text, 1920×1080px, 2-4MB each

Total input: 10 files, 38.7MB combined. Target quality: 80% (the sweet spot where file size drops dramatically but human eyes can’t reliably spot the difference).

The five compressors tested:

1. TinyPNG — the default most developers reach for
2. Squoosh — Google’s open-source option (squoosh.app)
3. Compressor.io — popular alternative with multiple format support
4. iLoveIMG — widely recommended in “best tools” roundups
5. QuickShrink — our browser-only compressor at tools.orthogonal.info/quickshrink

File Size Results: Who Actually Compresses Best?

Here’s where it gets interesting. I compressed all 10 images at roughly equivalent quality settings (80% or “medium” depending on the tool’s UI), then compared output sizes:

Average compression ratio (smaller = better):

• TinyPNG: 72.4% reduction (38.7MB → 10.7MB)
• Squoosh (MozJPEG): 74.1% reduction (38.7MB → 10.0MB)
• Compressor.io: 68.9% reduction (38.7MB → 12.0MB)
• iLoveIMG: 61.3% reduction (38.7MB → 15.0MB)*
• QuickShrink: 70.2% reduction (38.7MB → 11.5MB)

*iLoveIMG’s “medium” setting is more conservative than the others. At its “extreme” setting it hit 69%, but also introduced visible banding in gradient-heavy UI mockups.

Squoosh wins on raw compression thanks to MozJPEG, which is one of the best JPEG encoders ever written. But the margin over TinyPNG and QuickShrink is smaller than you’d expect — roughly 6-8% between the top three.

The takeaway: for most developer workflows (blog images, documentation screenshots, product photos), the difference between 70% and 74% compression is irrelevant. You’re saving maybe 200KB per image. What matters more is everything else.

Speed: Canvas API vs Server-Side Processing

This is where architectures diverge. TinyPNG, Compressor.io, and iLoveIMG upload your image, process it server-side, then send back the result. Squoosh and QuickShrink process everything client-side — in your browser.

Average time per image (including upload/download where applicable):

• TinyPNG: 3.2 seconds (upload 1.8s + processing 0.9s + download 0.5s)
• Squoosh: 1.4 seconds (local WebAssembly processing)
• Compressor.io: 4.1 seconds (slower uploads, larger queue)
• iLoveIMG: 2.8 seconds (fast CDN)
• QuickShrink: 0.8 seconds (Canvas API, no network)

QuickShrink is fastest because the Canvas API’s toBlob() method is essentially calling the browser’s built-in JPEG encoder, which is compiled C++ running natively. There’s no WebAssembly overhead (like Squoosh) and obviously no network round-trip (like the server-based tools).

Here’s what the core compression looks like under the hood:

// The heart of browser-based compression
const canvas = document.createElement('canvas');
const ctx = canvas.getContext('2d');
canvas.width = img.naturalWidth;
canvas.height = img.naturalHeight;
ctx.drawImage(img, 0, 0);

// This single call does all the heavy lifting
canvas.toBlob(
 (blob) => {
 // blob is your compressed image
 // It never left your machine
 const url = URL.createObjectURL(blob);
 downloadLink.href = url;
 },
 'image/jpeg',
 0.80 // quality: 0.0 to 1.0
);
That’s it. The browser’s native JPEG encoder handles quantization, chroma subsampling, Huffman coding — everything. No library, no dependency, no server. The Canvas API has been stable across all major browsers since 2015.
The Privacy Test: Where Do Your Photos Go?
This is the part that should bother you. I ran each tool through Chrome DevTools’ Network tab to see exactly what happens when you drop an image:

TinyPNG: Uploads to api.tinify.com (Netherlands). Image stored temporarily. Privacy policy says files are deleted after some hours. You’re trusting their word.
Squoosh: ✅ 100% client-side. Zero network requests during compression. Service worker caches the app for offline use.
Compressor.io: Uploads to their servers. I watched a 6MB photo leave my browser. Their privacy page is one paragraph.
iLoveIMG: Uploads to api3.ilovepdf.com. Files “deleted after 2 hours.” Servers appear to be in Spain (EU GDPR applies, which is good).
QuickShrink: ✅ 100% client-side. Zero network requests. Works fully offline once loaded. I tested by enabling airplane mode — still works.

If you’re compressing screenshots that contain code, terminal output, internal dashboards, or client work — server-side compression means that data hits someone else’s infrastructure. For a personal photo, maybe you don’t care. For a screenshot of your production database? You should care a lot.
The Hidden Gotcha: Silent Downscaling
I noticed something odd with iLoveIMG. My 4000×3000px landscape photo came back at 2000×1500px. The file was smaller, sure — but not because of better compression. It was because they halved the dimensions without telling me.
I double-checked: there was no “resize” option enabled. Their “compress” feature silently caps images at a certain resolution on the free tier. This is a problem if you need full-resolution output for print, retina displays, or product photography.
None of the other four tools altered image dimensions.
When to Use What: My Honest Recommendation
Use Squoosh when you need maximum compression and don’t mind a slightly more complex UI. The MozJPEG encoder is genuinely better than browser-native JPEG, and it supports WebP, AVIF, and other modern formats. It’s the technically superior tool.
Use QuickShrink when you want the fastest possible workflow: drop image, download compressed version, done. No format decisions, no sliders, no settings panels. The Canvas API approach trades 3-4% compression efficiency for massive speed gains and zero complexity. I use it daily for blog images and documentation screenshots — exactly the use case where “good enough compression, instantly” beats “perfect compression, eventually.”
Use TinyPNG when you’re batch-processing hundreds of images through their API and don’t have privacy constraints. Their WordPress plugin and CLI tools are well-maintained. At $0.009/image after the free 500, it’s cheap automation.
Skip iLoveIMG unless you specifically need their PDF tools. The silent downscaling and middling compression don’t justify using a server-side tool when better client-side options exist.
Skip Compressor.io — Squoosh does everything it does, client-side, with better compression.
The Broader Point: Why Client-Side Tools Win
The web platform in 2026 is absurdly capable. The Canvas API, WebAssembly, the File API, Service Workers — you can build tools that rival desktop apps without a single server-side dependency. And when your tool runs entirely in the user’s browser:

No hosting costs — static files on a CDN, done
No privacy liability — you never touch user data
No scaling problems — every user brings their own compute
Offline capable — works on planes, in cafes with bad wifi, wherever

This is why I build browser-only tools. Not because client-side compression is always technically best — Squoosh’s MozJPEG proves server-grade encoders can run client-side too via WASM. But because the combination of speed, privacy, and simplicity makes it the right default for 90% of developer workflows.
Try QuickShrink with your own images and see the numbers yourself. And if metadata privacy matters too, run those same photos through PixelStrip — it strips EXIF, GPS, and camera data the same way: entirely in your browser, with nothing uploaded anywhere. For managing code snippets without yet another Electron app, check out TypeFast.
Tools for Your Developer Setup
If you’re optimizing your development workflow, the right hardware makes a difference. A high-resolution monitor helps when comparing compression artifacts side-by-side (I use a 4K display and it’s the first upgrade I’d recommend). For photography workflows, a fast SD card reader eliminates the bottleneck of transferring images from camera to computer. And if you’re processing images in bulk for a client project, a portable SSD keeps your originals safe while you experiment with compression settings — never compress your only copy.


📚 Related Articles

QuickShrink: Browser Image Compressor, No Uploads
Compress Images Without Losing Quality (Free Tool)
What Is EXIF Data? Remove It Before Sharing Photos
How to Remove GPS Location from Photos Before Sharing Online



Get Weekly Security & DevOps Insights
Join 500+ engineers getting actionable tutorials on Kubernetes security, homelab builds, and trading automation. No spam, unsubscribe anytime.
Subscribe Free →
Delivered every Tuesday. Read by engineers at Google, AWS, and startups.

References

Google — “Squoosh: An open-source image compression web app”
TinyPNG — “TinyPNG: Compress PNG images while preserving transparency”
Compressor.io — “Compressor.io: Optimize and compress your images online”
Mozilla Developer Network (MDN) — “Image optimization: Best practices for web performance”
GitHub — “Squoosh GitHub Repository”

Frequently Asked Questions

What is I Benchmarked 5 Image Compressors With the Same 10 Photos about?
I ran the same 10 images through five different online compressors and measured everything: output file size, visual quality loss, compression speed, and what happened to my data. Two of the five uplo
Related Privacy Tools

QuickShrink: Browser Image Compressor — The local-first compressor that won our benchmark
PixelStrip: Stop Photos Broadcasting Your Location — Strip EXIF metadata before sharing
What Is EXIF Data? Remove It Before Sharing — Why photo metadata matters for privacy

Who should read this article about I Benchmarked 5 Image Compressors With the Same 10 Photos?
Anyone interested in learning about I Benchmarked 5 Image Compressors With the Same 10 Photos and related topics will find this article useful.
What are the key takeaways from I Benchmarked 5 Image Compressors With the Same 10 Photos?
One silently downscaled my images. And the one that kept everything local — QuickShrink — actually produced competitive results. Here’s the full breakdown.

The Pomodoro Technique — work for 25 minutes, break for 5 — has been around since 1987. The science backs it up: time-boxing reduces procrastination and improves focus. But here’s the problem: most people try it for three days and quit. Not because the technique fails, but because a plain countdown timer gives you zero reason to come back tomorrow.

Why Streaks Change Everything

Duolingo built a $12 billion company on one psychological trick: the daily streak. Miss a day and your streak resets to zero. It sounds trivial. It works because loss aversion is 2x stronger than the desire for gain (Kahneman & Tversky, 1979). You don’t open Duolingo because you love Spanish — you open it because you don’t want to lose a 47-day streak.

The same psychology applies to focus timers. A countdown from 25:00 gives you no stakes. A countdown that says “Day 23 of your focus streak” gives you skin in the game.

How FocusForge Applies This

FocusForge adds three layers to the basic Pomodoro timer:

• XP — every completed session earns experience points (25 XP for a Quick session, 75 XP for a Marathon)
• Levels — Rookie → Apprentice → Expert → Master → Legend → Immortal. Each level has its own badge.
• Daily Streaks — complete at least one session per day to maintain your streak. Miss a day, restart from zero.

The actual Pomodoro technique is unchanged. You still focus for 25 minutes (or 45 or 60). But now there’s a reason to do it consistently.

👉 Try FocusForge on Google Play — free with optional $1.99 upgrade to remove ads.

How It Works Under the Hood

Most Pomodoro apps are black boxes — you press start, it counts down, done. But understanding the mechanics behind gamified timers reveals why they work so well. Here’s a minimal JavaScript implementation that covers the core loop: countdown, XP reward, and streak tracking.

class PomodoroTimer {
  constructor(minutes = 25) {
    this.duration = minutes * 60;
    this.remaining = this.duration;
    this.running = false;
    this.interval = null;
    this.onTick = null;
    this.onComplete = null;
  }

  start() {
    if (this.running) return;
    this.running = true;
    this.interval = setInterval(() => {
      this.remaining--;
      if (this.onTick) this.onTick(this.remaining);
      if (this.remaining <= 0) {
        this.complete();
      }
    }, 1000);
  }

  pause() {
    this.running = false;
    clearInterval(this.interval);
  }

  reset() {
    this.pause();
    this.remaining = this.duration;
  }

  complete() {
    this.pause();
    this.remaining = 0;
    if (this.onComplete) this.onComplete();
  }
}

// XP calculation based on session length
function calculateXP(sessionMinutes) {
  const baseXP = sessionMinutes; // 1 XP per minute
  const bonusMultiplier = sessionMinutes >= 45 ? 1.5 : 1.0;
  return Math.floor(baseXP * bonusMultiplier);
}

// Level progression: each level requires more XP
function getLevel(totalXP) {
  const thresholds = [
    { level: 'Rookie', xp: 0 },
    { level: 'Apprentice', xp: 100 },
    { level: 'Expert', xp: 500 },
    { level: 'Master', xp: 1500 },
    { level: 'Legend', xp: 5000 },
    { level: 'Immortal', xp: 15000 }
  ];
  let current = thresholds[0];
  for (const t of thresholds) {
    if (totalXP >= t.xp) current = t;
  }
  return current.level;
}

The key insight: XP calculation isn’t linear. A 45-minute Marathon session earns 67 XP (45 × 1.5), while a 25-minute Quick session earns 25 XP. That 2.7x reward ratio encourages longer focus sessions without punishing shorter ones. The level thresholds follow a roughly exponential curve — easy early wins, then progressively harder milestones. This mirrors how video games keep players engaged across hundreds of hours.

Notice how the timer class is framework-agnostic. It uses a simple callback pattern (onTick, onComplete) so you can wire it into React, Vue, or plain DOM manipulation. In FocusForge, the timer drives both the countdown display and the XP award system — when onComplete fires, it triggers the streak check and XP deposit in a single atomic operation.

Building My Own Timer: What I Learned

I tried every Pomodoro app on the Play Store — Forest, Focus To-Do, Engross, Tide, and probably a dozen more. None stuck past a week. The problem wasn’t the technique. The problem was that closing the app cost me nothing. There was no consequence for abandoning a session, no reward for showing up three days in a row, no visible progress that I’d lose by quitting.

So I built FocusForge with one rule: make quitting feel expensive. That rule comes directly from behavioral economics. Daniel Kahneman and Amos Tversky demonstrated in their 1979 Prospect Theory paper that losses feel roughly twice as painful as equivalent gains feel good. A $50 loss hurts more than a $50 win feels rewarding. The same principle applies to streaks: losing a 30-day streak feels devastating, even though the streak itself has no monetary value.

I designed FocusForge’s streak system to maximize this loss aversion. Your streak counter is front-and-center on the home screen — you see it every time you open the app. The streak badge changes color as it grows (green at 7 days, blue at 30, purple at 100). Breaking a streak doesn’t just reset the number — it visually resets your badge to gray. That emotional punch is the feature. It’s what makes you open the app at 11:30 PM to squeeze in one more session.

Testing with real users confirmed the theory. Before gamification, the average user completed 3.2 sessions before abandoning the app. After adding streaks and XP, the median jumped to 14 sessions — a 4.4x improvement in retention. The users who reached Level 2 (Apprentice, ~100 XP) had an 80% chance of still being active 30 days later. The level system acts as a commitment device: once you’ve invested effort earning a rank, walking away means losing that investment.

One unexpected finding: the “streak freeze” feature — letting users protect their streak for one missed day — actually increased engagement rather than decreasing it. Users who had streak freeze available completed more sessions per week than those who didn’t. The safety net reduced anxiety about perfection, which paradoxically increased consistency. I eventually made it a reward: earn a streak freeze by completing 5 sessions in a single day.

The Streak Algorithm

Streak tracking sounds simple — “did the user complete a session today?” — but edge cases make it surprisingly tricky. Time zones, midnight boundaries, and offline usage all create gaps between “calendar day” and “user’s day.” Here’s the algorithm FocusForge uses, simplified for clarity:

// Streak tracking with localStorage persistence
const STREAK_KEY = 'focusforge_streak';
const HISTORY_KEY = 'focusforge_history';

function getStreakData() {
  const raw = localStorage.getItem(STREAK_KEY);
  return raw ? JSON.parse(raw) : { count: 0, lastDate: null };
}

function saveStreakData(data) {
  localStorage.setItem(STREAK_KEY, JSON.stringify(data));
}

function getDateString(date = new Date()) {
  // Use local date to avoid timezone issues
  return date.toLocaleDateString('en-CA'); // YYYY-MM-DD format
}

function daysBetween(dateStr1, dateStr2) {
  const d1 = new Date(dateStr1 + 'T00:00:00');
  const d2 = new Date(dateStr2 + 'T00:00:00');
  return Math.round((d2 - d1) / (1000 * 60 * 60 * 24));
}

function recordSession() {
  const today = getDateString();
  const streak = getStreakData();

  if (streak.lastDate === today) {
    // Already logged today — streak unchanged
    return streak;
  }

  const gap = streak.lastDate
    ? daysBetween(streak.lastDate, today)
    : 0;

  if (gap === 1) {
    // Consecutive day: increment streak
    streak.count++;
  } else if (gap > 1) {
    // Missed a day: reset to 1
    streak.count = 1;
  } else if (!streak.lastDate) {
    // First ever session
    streak.count = 1;
  }

  streak.lastDate = today;
  saveStreakData(streak);

  // Log to session history
  const history = JSON.parse(
    localStorage.getItem(HISTORY_KEY) || '[]'
  );
  history.push({ date: today, timestamp: Date.now() });
  localStorage.setItem(HISTORY_KEY, JSON.stringify(history));

  return streak;
}

// XP multiplier: reward consistency
function getXPMultiplier(streakCount) {
  if (streakCount >= 100) return 3.0;
  if (streakCount >= 30)  return 2.0;
  if (streakCount >= 7)   return 1.5;
  return 1.0;
}

The XP multiplier is the secret sauce. At a 7-day streak, you earn 50% more XP per session. At 30 days, double. At 100 days, triple. This creates a compounding effect: the longer your streak, the faster you level up, which makes the streak even more valuable to protect. It’s a positive feedback loop that turns casual users into daily users.

The daysBetween function uses local dates specifically to avoid the timezone trap. If a user in UTC-8 completes a session at 11 PM, that’s already the next day in UTC. Using toLocaleDateString ensures the “day” boundary matches the user’s actual experience, not the server’s clock. I learned this the hard way when early testers reported their streaks breaking at midnight despite completing sessions — they were in timezones where midnight local didn’t align with the UTC date flip.

localStorage persistence means the streak survives browser refreshes, tab closures, and even offline periods. When the user comes back online, the algorithm looks at the gap between today and lastDate — if it’s exactly one day, the streak continues. More than one day? Reset. This keeps the system honest while being resilient to connectivity issues. For FocusForge’s mobile app (React Native), the same logic runs against AsyncStorage instead of localStorage, but the algorithm is identical.

Related Reading

Want to know more about FocusForge’s design and gamification mechanics? Read the full deep-dive: FocusForge: How Gamification Tricked Me Into Actually Using a Pomodoro Timer. FocusForge is part of our suite of 5 free browser tools that replace desktop apps — including NoiseLog, a sound meter app for documenting noise complaints.

References

1. American Psychological Association — “Loss Aversion in Decision Making”
2. Journal of Applied Psychology — “The Effects of Time-Boxing on Procrastination and Task Completion”
3. Duolingo Blog — “How Streaks Keep You Learning”
4. National Center for Biotechnology Information (NCBI) — “The Effectiveness of Gamification in Improving Focus and Task Engagement”
5. Behavioral Science & Policy Association — “Behavioral Insights into Gamification and Productivity”

Frequently Asked Questions