Category: Tools & Setup

I spent last weekend comparing two config files — a 400-line nginx setup where I’d made changes across multiple servers. I opened Diffchecker.com, pasted both files, and immediately ran into the same frustrations I’ve had for years: the page uploaded my text to their server (privacy issue for config files), there were no keyboard shortcuts to jump between changes, and the character-level highlighting was either nonexistent or buried behind a Pro paywall.

So I built my own.

The Problem with Every Online Diff Tool

Here’s what bugs me about existing text comparison tools. I tested the top three before writing a single line of code:

Diffchecker.com — The default recommendation on every “best tools” list. It works, but your text gets sent to their servers. For comparing code, configs, or anything with credentials nearby, that’s a non-starter. They also paywall basic features like “find next difference” behind a $10/month subscription.

TextDiffViewer.com — Claims client-side processing, which is good. But the UI feels like it was built in 2012. No character-level highlighting within changed lines, no unified diff view, no keyboard shortcuts. If I’m comparing 2,000 lines, I need to jump between changes, not scroll manually.

DevToolLab’s Diff Checker — Clean UI, but limited. Only side-by-side view, no way to ignore whitespace or case differences, and no file drag-and-drop. Fine for small comparisons, frustrating for real work.

The pattern is clear: either the tool uploads your data (privacy problem) or it’s missing features that developers actually need (navigation, views, options). It’s the same reason I built RegexLab — Regex101 sends your patterns to their server, which is a deal-breaker when you’re testing patterns against production data.

What I Built: DiffLab

DiffLab is a single HTML file — no server, no dependencies, no uploads. Everything runs in your browser. Close the tab and your data is gone. Here’s what makes it different:

Three View Modes

Most diff tools give you side-by-side and call it a day. DiffLab has three views you can switch between with keyboard shortcuts:

• Side-by-side (press 1) — The classic two-column layout. Changed lines are paired, and character-level differences are highlighted within each line so you can see exactly what changed.
• Unified (press 2) — Like git diff output. Removed lines appear with a - prefix, added lines with +. Compact and scannable.
• Inline (press 3) — Shows old → new on the same line with character highlighting. Best for reviewing small edits across many lines.

Keyboard Navigation Between Changes

This is the feature I wanted most. In a long file with changes scattered throughout, scrolling to find each difference is painful. DiffLab tracks every change “hunk” and lets you:

• Press J or ↓ to jump to the next change
• Press K or ↑ to jump to the previous change
• A floating indicator shows “Change 3 of 12” so you always know where you are

The current change gets a visible highlight so your eye can find it instantly after scrolling.

Character-Level Highlighting

When a line changes, DiffLab doesn’t just highlight the whole line red/green. It finds the common prefix and suffix of the old and new line, then highlights only the characters that actually changed. If you renamed getUserById to getUserByName, only Id and Name get highlighted — not the entire function call.

Comparison Options

Two toggles that matter for real-world comparisons:

• Ignore whitespace (W) — Treats a b and a b as identical. Essential for comparing code with different formatting.
• Ignore case (C) — Treats Hello and hello as identical. Useful for config files where case doesn’t matter.

Both options re-run the diff instantly when toggled.

How It Works Under the Hood

The Diff Algorithm

DiffLab uses a Myers diff algorithm — the same algorithm behind git diff. It finds the shortest edit script (minimum number of insertions and deletions) to transform the original text into the modified text.

For inputs under 8,000 total lines, it runs the full Myers algorithm. For larger inputs, it switches to a faster LCS-based approach with lookahead that trades perfect minimality for speed. In practice, both produce identical results for typical comparisons.

The algorithm runs in your browser’s main thread. On my laptop, comparing two 5,000-line files takes about 40ms. The rendering is the bottleneck, not the diff calculation.

Character Diffing

For paired changed lines (a removed line followed by an added line at the same position), DiffLab runs a second pass. It finds the longest common prefix and suffix of the two strings, then wraps the changed middle section in highlight spans. This is simpler than running a full diff on individual characters, but it’s fast and catches the common case (a word or variable name changed in the middle of a line) perfectly.

Rendering Strategy

The diff output renders as an HTML table. Each row is a line, with cells for line numbers and content. I chose tables over divs because:

1. Line numbers stay aligned with content automatically
2. Column widths distribute properly in side-by-side mode
3. Screen readers can navigate the structure

Changed lines get CSS classes (diff-added, diff-removed) that map to CSS custom properties. Dark mode support comes free through prefers-color-scheme media queries — the custom properties switch automatically.

Real Use Cases

I’ve been using DiffLab daily since building it. Here are the situations where it’s genuinely useful:

1. Comparing deployment configs — Before pushing a staging config to production, paste both and verify only the expected values changed.
2. Code review diffs — When a PR is too large for GitHub’s diff view, copy-paste specific files for focused comparison.
3. Database migration scripts — Compare the current schema dump with the new one to make sure nothing got dropped accidentally.
4. Documentation updates — Writers comparing draft versions to see what an editor changed.
5. API response debugging — Compare expected vs actual JSON responses. The character-level highlighting catches subtle differences in values. For formatting those JSON responses first, JSON Forge does the same client-side-only trick.

Privacy and Offline Use

DiffLab includes a service worker that caches everything on first visit. After that, it works completely offline — airplane mode, no internet, whatever. Your text never leaves the browser tab, and there’s no analytics tracking what you compare.

It also passes Chrome’s PWA install requirements. Click “Install” in your browser’s address bar and it becomes a standalone app on your desktop or phone.

Try It

DiffLab is live at difflab.orthogonal.info. Single HTML file, zero dependencies, works offline.

The keyboard shortcuts are the selling point: Ctrl+Enter to compare, J/K to navigate changes, 1/2/3 to switch views, W for whitespace, C for case, S to swap sides, Escape to clear.

If you compare text files regularly, give it a try. DiffLab is part of a growing set of free browser tools that replace desktop apps — all client-side, all offline-capable. If you build developer tools, I’d love to hear what’s missing — reach out at [email protected].

If you spend hours comparing code and config files, a good ergonomic keyboard makes the typing between comparisons much more comfortable. I switched to a split keyboard last year and my wrists thank me daily.

For monitor setups that make side-by-side diffs actually readable, check out these ultrawide monitors for programming — the extra horizontal space is worth it.

And if you’re doing serious code reviews, a monitor arm to position your screen at the right height reduces neck strain during long sessions.

References

1. OWASP — “OWASP Top Ten Privacy Risks”
2. Mozilla Developer Network (MDN) — “Client-Side Storage and Security”
3. GitHub — “Diff Tool: Client-Side Comparison Implementation”
4. NIST — “Guide to Protecting the Confidentiality of Personally Identifiable Information (PII)”
5. RFC Editor — “RFC 4949: Internet Security Glossary, Version 2”

Last Tuesday I was deep in a refactor — 40 files touched, tests half-green — when Slack lit up: “Production’s returning 500s, can you look at main?” My old workflow: git stash, switch branches, forget what I stashed, lose 20 minutes reconstructing state. My current workflow: git worktree add ../hotfix main, fix the bug in a separate directory, push, delete the worktree, and I never left my refactor. Total context-switch cost: zero.

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

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”

Last week I was debugging a CloudFront log parser and pasted a chunk of raw access logs into Regex101. Mid-keystroke, I realized those logs contained client IPs, user agents, and request paths from production. All of it, shipped off to someone else’s server for “processing.”

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

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