Text Tools
Tools for plain and structured text — formatting JSON, converting between JSON, YAML, CSV and XML, comparing two texts and testing regular expressions, all in your browser.
Quick tasks
One click opens the tool already set up for the job.
Online Text Tools - Format, Validate and Test Text in Your Browser
Text is the format developers actually work in. Configuration arrives as JSON, log lines get filtered with regular expressions, API responses are read as text long before they become objects. The tools in this category handle that everyday work in the browser, without an account and without sending anything to a server.
Every tool here runs entirely client-side. The text you paste stays in the tab: it is processed by JavaScript on your own machine and never travels over the network. That matters more than it sounds, because the text a developer needs to format is very often the text they are least allowed to paste into a random website - a production API response, a customer record, a token, a config file with credentials in it.
What is in this category
| Tool | What it does | Reach for it when |
|---|---|---|
| JSON Formatter | Indents, validates and minifies JSON, and points at the exact character where parsing failed | An API response is one unreadable line, or something rejects your payload as malformed |
| Regex Tester | Runs a regular expression against sample text as you type, highlights every match and breaks out capture groups | You are writing a pattern for a log filter, a validation rule or a search-and-replace |
| JSON Converter | Converts between JSON, YAML, CSV and XML in any direction, flattening nested JSON into columns for CSV | A config has to be YAML, an export has to open in Excel, or an old service only speaks XML |
| Text Compare | Shows every added, removed and changed line between two texts, with the changed words marked | Two versions of a contract, a config file or a function look the same but are not |
| Case Converter | Turns text into UPPER CASE, lower case, Title Case, camelCase, snake_case, kebab-case or a URL slug, all at once | A heading was typed with Caps Lock on, or a list of names has to become variable names or web addresses |
| Word Counter | Counts words, characters, sentences and reading time as you type, removes duplicate lines and makes Lorem ipsum | A text has to fit a limit, a list is full of repeats, or a layout needs filler text |
| Markdown to HTML Converter | Renders Markdown to HTML with a live preview, and turns HTML back into Markdown | A README needs checking before it is pushed, or web content has to move into Markdown |
Formatting and validating JSON
Minified JSON is what machines send and what humans cannot read. Pasting it into the JSON formatter indents it, sorts the structure visually and makes the shape of the data obvious - which array is nested inside which object, where the null is, whether that number is really a string.
The validation half matters just as much. When JSON fails to parse, most tools tell you only that it is invalid. A useful formatter names the character offset and the reason: a trailing comma after the last element, a single quote where JSON demands a double, an unescaped newline inside a string, a stray BOM at the start of a file. Those five account for the large majority of real-world JSON errors, and all five are invisible when you are scanning a wall of text by eye.
Minifying is the same operation in reverse, and it is worth doing before you paste a payload into a curl command, an environment variable or a database column where whitespace is dead weight.
Converting between JSON, YAML, CSV and XML
The same data often has to travel in a different format: JSON from an API into a YAML manifest, a JSON array into a spreadsheet, a CSV export into a JSON import, or XML from an old service into something JavaScript can use. The JSON converter does all of these in one place. Nested JSON becomes dotted column names such as address.city when it goes to CSV, XML attributes become @ keys, and broken input is reported with a line and column rather than an empty result.
Comparing two versions of a text
When a file changed and you need to know exactly how, reading both versions side by side is slow and unreliable. Text Compare uses the same Myers algorithm as Git to find the smallest set of added and removed lines, then marks the changed words inside each changed line. It can ignore whitespace or case, and it copies the result as a unified diff that git apply accepts.
Testing regular expressions before they reach production
A regular expression is code that is unusually easy to get wrong and unusually hard to read afterwards. The reliable way to write one is to build it against real sample text and watch the matches change as you go, which is exactly what the regex tester is for: paste a few representative lines, type the pattern, and see immediately what it catches and what it misses.
The cases worth testing deliberately are the ones that bite later. Does the pattern still work when the line is empty? When there is trailing whitespace? When the same match appears twice on one line - does the g flag actually catch both? Is . supposed to cross a newline, and have you set the s flag accordingly? Are your capture groups numbered the way you expect once you add a group for grouping rather than for capturing?
Greediness is the classic trap. <.*> against <a>text</a> matches the whole string, not the first tag, because * takes as much as it can. <.*?> takes as little as it can and matches only <a>. Seeing that difference highlighted is faster than reasoning about it.
How these tools fit into a normal day
- An endpoint returns 200 but the client breaks: format the body, and the missing field is obvious in seconds.
- A log file needs one field extracted from ten thousand lines: build the pattern against five sample lines first, then run it for real.
- A config file is rejected at deploy time: validate it locally before pushing another commit to find out.
- A colleague sends a payload in chat with the newlines stripped: paste, format, read.
- You are writing a validation rule and need to know what it accepts before users find the gap.
Why client-side processing is the point
Most online formatters POST your text to a server, format it there and send it back. That is a data transfer you usually have no reason to make, and often are not permitted to make. Anything with a customer name, an access token, an internal hostname or an unreleased schema in it is exactly the kind of text that should not leave the machine.
The tools here use the browser's own JSON parser and regular-expression engine, so there is nothing to upload. You can confirm it: open your browser's network tab, paste a large payload, format it, and watch that no request is made. The page works offline too, once it has loaded.
Related categories
- Encoding tools - when the text needs to become Base64 or percent-encoded rather than reformatted.
- Developer tools - hashing, timestamps, colour conversion and JWT decoding, which is text work of a different shape.
- Generator tools - for producing identifiers, passwords and QR codes instead of transforming text you already have.
Frequently confused: formatting, validating and minifying
Formatting (also called beautifying or pretty-printing) changes only whitespace so a human can read the structure. Validating answers a yes-or-no question - is this parseable - and, when the answer is no, says where it broke. Minifying strips every byte that a parser does not need. The three are independent: valid JSON can be unreadable, and readable JSON can be invalid. A good formatter does all three, which is why it is usually the first tool a developer opens.