Code Tools
JSON, Base64 & Regex Utilities
These three cover the small jobs that eat real time: untangling a minified API response, decoding a Base64 blob to see what is actually inside, and figuring out why a regex does not match. They all run in the tab, so a payload, a token or a customer's log line never leaves your machine.
JSON Formatter & Validator
Validate, pretty-print and minify JSON, with exact line/column error reporting.
Base64 Encoder / Decoder
UTF-8-safe encode and decode for text, files and data URIs.
Regex Tester & Debugger
Live match and capture-group highlighting with clear error hints.
Which tool for which mess
JSON Formatter is for the one-line response curl hands you and the minified config someone committed. Paste it and it pretty-prints with 2- or 4-space indent, or minifies it back down before you save. It also normalizes whitespace, so reformatting before a commit keeps the diff clean instead of a wall of changed lines.
Base64 is for the middle segment of a JWT when you want to read the claims without a library, data URIs (data:image/png;base64,…), and the occasional blob someone pasted into a ticket. The encoder handles UTF-8 properly: native btoa() throws on anything outside Latin-1, which is what bites people the moment an accented character or emoji shows up.
Regex Tester is for validating input before it reaches a backend, or picking fields out of log lines. Matches and capture groups highlight as you type, and the error text tells you why a pattern is malformed instead of just saying “invalid”.
The things that bite
- JSON is stricter than JS. Single quotes, trailing commas, unquoted keys and comments are all invalid. Duplicate keys do not error:
JSON.parsekeeps only the last one. - Numbers lose precision. JSON numbers are IEEE-754 doubles, so integers past 2^53 come back rounded when you re-serialize.
- Base64 has two dialects. URL-safe Base64 swaps
+and/for-and_. Feeding one into the other produces garbage with no error. - Regex can hang. Nested quantifiers like
(a+)+on a long non-match trigger catastrophic backtracking and freeze the tab. - Lookbehind isn't everywhere.
(?<=…)works in Chrome but throws in Safari before 16.4, so a pattern that tests fine on your machine may break someone else's.
A typical pass through all three
Pull a response from staging with curl, drop the JSON in the formatter to see its shape, check a field's format against the schema in the regex tester, then Base64-encode a header for the next request. Three tabs of small work, none of it leaving the browser. The one thing to watch: all three are synchronous, so a multi-megabyte JSON payload or a pathological regex will stall the tab: split big inputs first.
Why these tools stay in the browser
All three utilities are thin wrappers around abilities the browser already ships. JSON parsing and serialization come from the native JSON object, Base64 conversion sits in the platform's btoa and atob functions, and regular expression matching belongs to the RegExp core described by the ECMAScript specification. Nothing here needs a server, because every operation follows a published web standard and executes inside the browser engine itself. Your data is read and written only in the tab's memory, and no network request carries it away. That is the point of a client-side tool: the machine doing the work is the machine you already trust, and the only cost is the CPU and RAM the tab uses while it runs.
The tradeoff is honest. Heavy work uses your CPU and RAM, and a multi-megabyte JSON document can stall the tab.
The standards behind each format
Each tool leans on a different specification. The JSON formatter validates and pretty-prints against RFC 8259, the document that defines the JSON data interchange syntax, so it knows exactly which constructs are legal. The Base64 encoder follows the alphabet laid out in RFC 4648, including the padding rules and the URL-safe variant that swaps + and / for - and _. The regex tester uses the pattern grammar the ECMAScript specification describes, which is the same engine your JavaScript runs under. The three standards sit at different layers: RFC 8259 governs a data interchange format, RFC 4648 governs the encoding of bytes, and ECMAScript governs a programming language.
So a single quote is a syntax error that the formatter reports, because RFC 8259 only allows double quotes.
Choosing the right one
Reach for the JSON formatter when an API response or config file arrives as one long line and you need to see its shape, or before committing so that whitespace changes do not flood the diff. Use the Base64 tool when you want to read the middle segment of a JWT, inspect an embedded data URI, or decode a blob someone pasted into a ticket. Turn to the regex tester when you need to validate input before it reaches a backend or pull fields out of log lines with instant feedback on groups and errors. If a payload survives a round trip through both sides of the encoder without changing, the tool did its job.
The three overlap less than they seem. Choosing mostly comes down to what you are looking at.
The standards behind these code utilities
- RFC 8259: The JSON Data Interchange Syntax. This is the grammar the formatter validates against, including the rule that strings use double quotes only.
- RFC 4648: The Base16, Base32, and Base64 Data Encodings. Defines the Base64 alphabet, padding, and the URL-safe variant that this encoder and decoder follow.
- MDN: The JSON object. Documents the native parse and stringify behavior the formatter relies on, including how duplicate keys are handled.
- MDN: btoa and atob. Explains the Latin-1 limitation behind the warning that native btoa throws on accented characters and emoji.
- MDN: Regular expressions guide. Covers the pattern syntax and features such as lookbehind that the tester checks, plus notes on backtracking behavior.