Dev Tools
Browser-based utilities for developers - format, encode, and validate without leaving the tab.
These tools handle common developer tasks - inspecting API responses, encoding tokens, validating configs - without sending your data anywhere. Everything runs locally in your browser.
About these dev utilities
Working developers reach for a small handful of utilities dozens of times a day: pretty-printing a JSON response so you can actually read it, validating that a config file parses, encoding a token for a header, decoding a Base64 blob to see what's inside. Most of these tasks take five seconds - but only if the tool is one tab away. Switching to a CLI, a notebook, or a heavyweight IDE for a five-second job is friction.
Critically, every operation here runs in your browser. None of the text you paste in - payloads, tokens, configs - leaves your machine. Pasting credentials or production API responses into random web tools is a common security mistake; these tools are designed so you don't have to.
Common use cases
- Reading API responses. Curl-ing an endpoint and getting back a wall of unindented JSON is normal. The JSON formatter beautifies it instantly with proper indentation; if the JSON is invalid, it shows you exactly which character or line is wrong.
- Encoding for HTTP headers. Basic Auth headers expect a
username:passwordpair Base64-encoded. The Base64 tool handles this without the round-trip to a terminal. - Decoding tokens and tokens-of-tokens. JWTs (the parts before the signature), data URIs, embedded image payloads - all Base64. Decode to see what's actually inside before treating it as opaque.
- Minifying for production. The JSON formatter has a minify mode for shrinking config files or payloads before transmission.
- Sanity-checking configs. Pasting a
package.jsonor Kubernetes manifest into a validator is the fastest way to confirm the syntax is clean before committing.
How JSON and Base64 actually work
JSON is a text format - what you see is what's stored. Whitespace is purely cosmetic; {"a":1} and the same object across three indented lines are identical to a parser. The reason "format" matters at all is human readability: a 200-line JSON response is unreadable on one line and trivially scannable when properly indented.
Base64 is an encoding, not encryption. It takes binary or text data and represents it using only 64 ASCII characters (A–Z, a–z, 0–9, +, /, plus = padding) so the data can travel safely through systems that mangle non-printable bytes - email headers, URL parameters, basic auth. Encoded output is roughly 33% larger than the input. Anyone can decode it; never use Base64 to "hide" sensitive data.
Frequently asked questions
Is Base64 secure?
No. Base64 is reversible by anyone in milliseconds. If you're encoding something sensitive, the data must be encrypted first - Base64 is just transport packaging.
What's the size overhead of Base64?
About 33% - every 3 bytes of input become 4 characters of output, plus padding. A 100KB file becomes roughly 137KB encoded.
Why does my JSON validator say "Unexpected token" but the API uses it?
Often the response is valid JSON wrapped in something else (JSONP padding, XML envelope, BOM bytes). Strip the wrapper and revalidate.
Is JSONC or JSON5 supported?
The validator follows strict JSON (RFC 8259) - no comments, no trailing commas. Use a JSON5 parser if you need those features in your toolchain.
Can I trust pasting credentials into this tool?
The encoder runs entirely client-side. Open DevTools → Network and confirm: zero network calls happen during encoding or decoding. That said, never paste live production credentials into any browser tool you haven't verified yourself.