I spend most of my week in a Laravel controller, a React component, or the WP Adminify plugin codebase. And in every one of those, the actual "writing code" part is maybe half the job. The other half is the connective tissue: formatting a JSON blob an API just spat back, decoding the middle segment of a JWT to see why auth is failing, generating forty test UUIDs for a seeder, converting a Unix timestamp in a log line into something a human can read.
For years I did those the clumsy way — a throwaway Node script, jq if I could remember the syntax, or, most often, a random utility site with three ad banners and a cookie wall. The last option is what eventually pushed me to build toolz.dev. Too many of those sites quietly POST your input to a server for a job the browser can do locally, and I got tired of pasting bits of a client's config into a stranger's backend just to pretty-print it.
This guide is the actual toolkit — the coding tools I keep bookmarked and open several times a day. Every one runs entirely in your browser, so the data never leaves your machine, and none of them ask you to sign up. I'll go through each one the way I use it, where it saves real time, and the mistakes I've made so you don't have to repeat them.
TL;DR: For API work, JSON Formatter beautifies and validates, and Base64 Converter decodes tokens and data URIs. For pattern matching, Regex Builder tests patterns live. For IDs, UUID Generator makes v1/v4/v7 in bulk. For debugging, Timestamp Converter turns epoch seconds into readable dates, and Hash Generator does MD5/SHA. All client-side, all free.
Why Use a Standalone Tool Instead of Your IDE or the Terminal?
I get this question from other devs, and it's fair — VS Code has extensions, and the terminal has jq, openssl, and base64 built in. So why open a browser tab?
The honest answer is friction and context. CLI tools are fantastic when they're already in a script you run repeatedly. But for a one-off — "what's inside this token right now" — the cost of remembering openssl dgst -sha256 or getting the jq filter syntax right is higher than the task itself. IDE extensions solve some of that, but they're tied to one editor, they need installing and configuring, and half of them haven't been updated in two years. When I'm SSH'd into a box, on a colleague's machine, or on my phone, none of that setup exists.
A browser tool sidesteps all of it. It does one job, exposes exactly the options that job needs, and it's the same on every device. The three I'd call permanent bookmarks are JSON formatting, regex testing, and Base64 decoding — the rest are situational but still faster than the alternative for a quick pass.
There's a privacy angle too, and it's the whole reason toolz.dev is browser-first. Every tool here processes your input with JavaScript in your own tab. There's no upload, no server round-trip, no log of what you pasted. That matters when the "input" is a JWT with a live session in it, a .env file, or a customer record you're only supposed to be debugging.
How Do You Format and Validate JSON Quickly?
JSON is the language everything speaks — REST APIs, config files, log pipelines, half the databases I touch. And raw JSON, especially a minified response, is unreadable. Here's a real shape of thing I deal with constantly:
{"users":[{"id":1,"name":"Alice","roles":["admin","editor"],"settings":{"theme":"dark","notifications":{"email":true,"push":false}}},{"id":2,"name":"Bob","roles":["viewer"],"settings":{"theme":"light","notifications":{"email":false,"push":true}}}]}
Finding whether Bob has push notifications on means scanning that character by character. Paste it into the JSON Formatter and it becomes an indented tree in one click. Beyond beautifying, the part I lean on most is validation — it points at the exact line where a trailing comma or an unescaped quote broke the document, which is a genuine time-saver when an API is handing you something almost-but-not-quite valid.
The four things it does that I actually use:
- Beautify with 2-space, 4-space, or tab indentation (I use 2 to match Prettier defaults).
- Minify to strip whitespace before shipping a payload.
- Validate with an error message that names the position, not just "invalid JSON".
- Tree view for navigating deeply nested responses without counting brackets.
A mistake I made early and now warn everyone about: I once "fixed" a config by pasting it into a formatter that silently accepted JSON5-style trailing commas and comments, then wondered for an hour why the strict parser in production rejected it. A good validator holds you to the actual JSON spec (ECMA-404 / RFC 8259) — no comments, no trailing commas, double-quoted keys — which is exactly what you want before you deploy. For the full workflow, formats, and conversion tricks, I wrote a dedicated JSON tools guide.
What Is Base64 Actually For, and When Do You Need It?
Base64 is one of those things every developer runs into but few stop to understand until it bites them. It converts binary data into a 64-character ASCII alphabet so it survives transport through text-only channels. It is not encryption and not compression — it makes data roughly 33% larger — it just makes bytes safe to paste into text.
Where I hit it in practice:
- JWTs — the header and payload are Base64url-encoded JSON. Decode the middle segment to see claims and expiry.
- Data URIs — embedding a small icon straight into CSS with
data:image/png;base64,...to save an HTTP request. - HTTP Basic Auth — credentials get Base64-encoded into the
Authorizationheader. - Config and secrets — Kubernetes secrets, for instance, store values Base64-encoded (which people constantly mistake for encryption — it is not).
The Base64 Converter encodes and decodes instantly: paste, pick a direction, copy. The one gotcha worth knowing is the difference between standard Base64 and the URL-safe variant defined in RFC 4648 — URL-safe swaps +/ for -_ and drops the padding, which is what JWTs use. Feed a JWT segment to a decoder that expects standard Base64 and it'll choke on the missing padding. I explain the algorithm, the URL-safe variant, and the Unicode trap that catches btoa() in the full Base64 encoding guide.
How Do You Build a Regex Without Guessing?
Regular expressions are the most powerful and most frustrating thing in the toolkit at the same time. The syntax is dense, unforgiving, and a single misplaced quantifier changes what a pattern matches. The reason a visual builder matters is that it turns the write-test-fail-rewrite loop into a live one — you see matches highlight as you type.
These are the patterns I've validated and reuse constantly:
| Pattern | Matches | Example |
|---|---|---|
^[\w.%+-]+@[\w.-]+\.[A-Za-z]{2,}$ |
Practical email | [email protected] |
^https?://[\w\-.]+\.\w+ |
URL | https://toolz.dev |
^\d{3}-\d{3}-\d{4}$ |
US phone | 555-123-4567 |
^(?:(?:25[0-5]|2[0-4]\d|[01]?\d?\d)\.){3}(?:25[0-5]|2[0-4]\d|[01]?\d?\d)$ |
IPv4 | 192.168.1.1 |
^#(?:[A-Fa-f0-9]{6}|[A-Fa-f0-9]{3})$ |
HEX color | #4466EE |
^\d{4}-\d{2}-\d{2}$ |
ISO date | 2026-07-11 |
Paste one into the Regex Builder, drop in a few test strings, and toggle the g/i/m flags to watch what changes. The single biggest lesson I've learned here is to avoid catastrophic backtracking — a pattern like ^(a+)+$ looks harmless but freezes on a long non-matching input because the engine explores an exponential number of paths. That's a real denial-of-service vector, not a curiosity. I go deep on that, plus a full cheat sheet and language-specific quirks, in the Regex Builder guide.
Which UUID Version Should You Generate?
Universally Unique Identifiers are 128-bit values you can generate independently on millions of machines without coordination and still trust to be unique. If you build anything distributed — microservices, offline-first apps, sharded databases — you need them. The catch is that there are several versions and most people reach for the wrong one out of habit.
The short version of what I recommend in 2026:
- v4 (random) — 122 random bits, no time or hardware leakage. The safe default when you don't need ordering.
- v1 (timestamp + MAC) — time-ordered but leaks the generating machine's MAC address. Avoid for new work.
- v7 (time-ordered + random) — a millisecond Unix timestamp followed by randomness, standardized in RFC 9562 (2024). This is my default for new database primary keys because it sorts well in a B-tree index without the privacy problems of v1.
The UUID Generator produces single or bulk IDs in any version with one click, which is exactly what I want when seeding a table. One thing I learned the expensive way: storing UUIDs as VARCHAR(36) instead of a native uuid/BINARY(16) type doubles the storage and slows every index comparison. On a table with millions of rows that's not a rounding error. The full breakdown of versions, database storage, and the v7-vs-auto-increment decision is in the UUID Generator guide.
How Do You Convert Between Unix Timestamps and Readable Dates?
Time is the single most error-prone area of programming, and I say that as someone who has shipped a bug because I mixed up seconds and milliseconds. Server logs speak Unix epoch, JavaScript speaks milliseconds, REST APIs speak ISO 8601, and email headers speak RFC 2822. Converting between them by hand is how you end up off by a factor of a thousand.
| Format | Example | Where you see it |
|---|---|---|
| Unix epoch (seconds) | 1783929600 |
Server logs, most APIs |
| Unix epoch (ms) | 1783929600000 |
JavaScript, Java |
| ISO 8601 | 2026-07-11T00:00:00Z |
REST APIs, JSON |
| RFC 2822 | Sat, 11 Jul 2026 00:00:00 +0000 |
Email headers |
The Timestamp Converter handles all of these with timezone support, which is what I open the moment a log line has a bare number in it. Worth knowing: the classic 32-bit signed Unix timestamp overflows on January 19, 2038 (the "Y2K38" problem), which is why anything storing time should use a 64-bit integer now. If you deal with logs daily, keep this one pinned.
What About YAML, Hashing, and Format Conversion?
These three round out the daily set even though I use them less than the headliners.
YAML is the config language of Kubernetes, Docker Compose, and GitHub Actions, and its indentation sensitivity makes it fragile — one stray tab (YAML forbids tabs for indentation) or an unquoted no that gets parsed as a boolean will break a deploy. The YAML Validator catches those instantly, and the XML to JSON and JSON to YAML converters handle the format shuffling when you're moving a config between systems.
Hashing is for integrity, not secrecy. I use the Hash Generator to verify a downloaded file against its published checksum, or to build content-hash cache keys. The rule that matters: MD5 and SHA-1 are fine for non-security checksums but broken for anything where an attacker could forge a collision — use SHA-256 or better there.
| Algorithm | Output | Use it for | Security |
|---|---|---|---|
| MD5 | 128-bit | Checksums, cache keys | Broken for security |
| SHA-1 | 160-bit | Legacy compatibility | Deprecated |
| SHA-256 | 256-bit | Signatures, integrity | Secure |
| SHA-512 | 512-bit | High-security hashing | Secure |
Format conversion — moving data between JSON, CSV, YAML, and XML — comes up constantly when I'm feeding an API's output into a spreadsheet or the reverse. Toolz.dev has JSON to CSV, CSV to JSON, and the XML/YAML converters above. The one caution: CSV can't represent nested structures, so any JSON-to-CSV of deeply nested data is lossy and needs flattening first. Always test on a small sample before you convert a big export.
What Does a Real Multi-Tool Workflow Look Like?
The tools get most of their value when you chain them, because real debugging is rarely one step. A concrete example from last month, debugging why a token was being rejected:
- Copied the JWT from a failing request header and split it on the dots.
- Pasted the middle (payload) segment into the Base64 Converter to decode it — remembering it's URL-safe Base64.
- Dropped the resulting JSON into the JSON Formatter to read the claims.
- Took the
expvalue (a Unix timestamp) and ran it through the Timestamp Converter — which showed the token had expired four hours earlier. Clock skew on the issuing server. Fixed in minutes instead of the afternoon it would have taken to add debug logging and redeploy.
That's the pattern: each tool does one thing, and the output of one feeds the next. Because it all runs client-side, none of that token data ever left my laptop, which is exactly what you want when the thing you're debugging is authentication.
A few habits that keep it fast: bookmark the five tools you touch most (toolz.dev also surfaces your recently used ones), lean on the standard clipboard shortcuts, and always validate configs, manifests, and patterns before a deploy — a syntax error a validator catches costs seconds; the same error caught in production costs an afternoon.
Frequently Asked Questions
What are the most essential coding tools for a web developer?
The core set I'd give any web developer is a JSON formatter and validator, a Base64 encoder/decoder, a regex tester, a UUID generator, a hash generator, and a timestamp converter. Those cover the overwhelming majority of the non-writing-code tasks that fill a normal day — inspecting API responses, decoding tokens, generating test data, and reading logs. Everything else is situational.
Are browser-based coding tools safe for sensitive data like tokens and keys?
It depends entirely on whether the tool processes data in your browser or on a server. Client-side tools like the ones on toolz.dev run in JavaScript in your own tab, so your input never gets uploaded or logged anywhere. Before pasting anything sensitive — a JWT, an API key, a .env value — into any online tool, confirm it's client-side. If a tool asks you to "upload" or shows a network request when you hit process, treat the data as exposed.
What is the difference between a JSON formatter and a JSON validator?
A validator answers one question — is this parseable JSON, yes or no — and if the answer is no, it tells you the line and column where the parse failed. A formatter re-prints valid JSON with consistent indentation so a human can read it. In practice they're the same operation: a formatter has to parse the input before it can pretty-print it, so any decent one reports the syntax error as a side effect. Reach for the validator's error message when a request is being rejected, and the formatter's output when a response is unreadable.
How do I decode a JWT safely?
Use a decoder that runs client-side, and never paste a live production token into anything you haven't verified. A JWT's header and payload are Base64url-encoded, not encrypted — anyone who has the token can read the claims, which is why the token itself is the secret. Decoding is fine for reading exp, iss, and the claims during debugging. Verifying the signature is a separate step that needs the signing key, and that key should never leave your server.
How do I convert a Unix timestamp to a readable date?
Paste the number into a timestamp converter and read the date back in UTC and in your local zone. The only real trap is the unit: a ten-digit number is seconds (the Unix convention, and what most backends emit), while a thirteen-digit number is milliseconds (the JavaScript convention). Feed milliseconds into a seconds parser and you land somewhere around the year 55,000 — an error that's obvious once you've seen it once and baffling the first time.
How do these tools compare to CLI utilities like jq and openssl?
CLI tools are more powerful and scriptable, and for anything repetitive that lives in a script, they win. Browser tools win for one-off, interactive work: there's nothing to install, no syntax to remember, and they work identically on any machine or phone. I use both — jq in pipelines, the browser formatter when I just need to eyeball one response. They're complementary, not competitors.
Can I use these tools offline?
They need a connection to load the page initially, but because the processing itself runs client-side, the actual work doesn't depend on a server after load. Some tools keep working if your connection drops mid-session. For guaranteed offline use, a Progressive Web App install or a desktop build is the more reliable route.
Why use browser tools instead of IDE extensions?
Browser tools are editor-agnostic and need zero setup, so they're available on a colleague's machine, a remote server, or your phone — anywhere an IDE and its extensions aren't installed and configured. They're ideal for quick tasks and for utilities your editor simply doesn't have a good plugin for. IDE extensions are better when the task is something you do inside one editor dozens of times a day.
Which UUID version should I default to in 2026?
For new database primary keys, UUID v7 — it's time-ordered for good index performance while staying globally unique, and it's now standardized in RFC 9562. Reach for v4 when you specifically want unpredictability, such as identifiers that shouldn't be guessable. Avoid v1 for anything new because it leaks the generating machine's MAC address.
Is Base64 a form of encryption?
No, and treating it as one is a common and dangerous mistake. Base64 is a reversible encoding that anyone can decode instantly — it exists to make binary data safe to transmit as text, not to hide it. Kubernetes secrets and Basic Auth headers use Base64, but that offers zero confidentiality; anything genuinely secret needs actual encryption on top.
The Short Version
The right small tool turns a two-minute chore into a two-second one, and across a week those seconds add up to real hours back. From formatting a JSON response to decoding a token, testing a regex, or reading a timestamp, these are the utilities I actually reach for — not because they're clever, but because they get out of the way.
Everything here lives on toolz.dev, runs entirely in your browser for privacy and speed, and never asks you to sign up. Start with the JSON Formatter and Regex Builder, then browse the full set of coding tools — there are 600+ free tools covering coding, text, PDF, and image work waiting when you need them.
