JSON & CSV Formatter / Validator

When you paste a blob of JSON that looks like {"name":"Alice","age":30,"active":true} into a formatter, the tool parses it into a structured tree, then rebuilds it with consistent indentation. The result is the exact same data, just arranged so humans can scan it quickly. Minifying does the reverse: it strips every unnecessary space and newline, turning three kilobytes of readable config into two kilobytes of dense text that machines process fractionally faster.

CSV formatting follows a similar logic but deals with rows and columns instead of nested objects. A messy spreadsheet export might have inconsistent quoting, trailing commas, or mixed delimiters. The formatter reads each row, identifies field boundaries, then rewrites every field with uniform quoting rules. Your data stays identical; only the punctuation becomes predictable. Because everything runs in JavaScript inside your browser, nothing touches a remote server, so sensitive datasets never leave your laptop.

JSON parsing follows a strict grammar defined in RFC 8259. The parser reads character by character, watching for opening braces, brackets, colons, and commas. When it sees a quote, it treats everything until the next unescaped quote as a single string value. Numbers must match a pattern like -12.34e5, and only four keywords exist: true, false, null, and nothing else. If any character violates the grammar, parsing halts and the validator flags the exact position.

CSV parsing uses RFC 4180 as a loose guide. Each line represents a row, and the chosen delimiter (comma, semicolon, tab, or pipe) marks column boundaries. When a field is wrapped in double quotes, the parser ignores delimiters inside those quotes. An escaped quote inside a quoted field appears as two consecutive quotes, so ""hello"" parses to the literal text "hello". Understanding these rules helps you debug malformed files. If a stray quote appears on row 47, the parser may swallow the next three rows before it notices anything wrong.

Imagine you hit a weather API and get back this response: {"city":"Denver","temp_f":58.3,"conditions":[{"time":"08:00","sky":"cloudy"},{"time":"14:00","sky":"sunny"}]}. It works, but reading it in Slack is painful. Paste it into the formatter, click Format, and you get a neatly indented version with each key on its own line. Now your colleague can instantly see that the conditions array holds two objects, one for morning and one for afternoon.

Next, you need to send that forecast data to a spreadsheet user who only understands CSV. Switch to the CSV tab, paste a quick JSON array like [{"city":"Denver","temp":58},{"city":"Boulder","temp":54}], and convert it to CSV. The output becomes city,temp followed by two data rows. Your teammate opens it in Excel without touching a JSON library. The whole round trip takes about fifteen seconds and zero server calls.

Developers often forget that the validator doubles as a debugging microscope. Suppose a webhook payload keeps failing silently. Paste the raw body into the validator, and if you see an error at character 312, you know exactly where to look. Maybe a field value contains an unescaped newline, or someone accidentally included a trailing comma after the last property. The pinpointed error saves you from scanning hundreds of lines manually.

Another underused trick involves config file migrations. Say you have 87 environment variables exported as semicolon-separated CSV from a legacy system, and your new container platform wants JSON. Paste the CSV, set the delimiter to semicolon, then convert. You instantly get a JSON array of objects ready to be transformed into a Kubernetes ConfigMap. Combining this with a simple find-and-replace in your editor, you can finish a migration that would otherwise involve writing a throwaway Python script.

The most common JSON error is a trailing comma. JavaScript engines often tolerate {"a":1,}, but strict JSON parsers reject it outright. If the validator complains near the end of an object, check for that extra comma lurking before the closing brace. Another frequent issue is unescaped special characters inside strings, like a literal tab or a backslash that should be written as a double backslash.

With CSV, trouble usually starts when fields contain the delimiter itself. A product name like "Widget, Large" will split into two columns unless the entire field is quoted. If your source file lacks proper quoting, the formatter cannot magically guess intent; it will parse Widget as one column and Large as another. Before converting, scan your data for embedded commas or semicolons, and ensure they are enclosed in double quotes. Spending thirty seconds on inspection prevents hours of corrupted imports downstream.