JSON Content Formatter

JSON is the format programs use to hand text to one another. It arrives as a long unbroken run of curly brackets, square brackets, quote marks and backslashes, which a program reads without difficulty and a person mostly cannot. This JSON content formatter turns that same content into something a person can actually read: titles look like titles, paragraphs like paragraphs, lists like lists. Nothing is added and nothing is thrown away. The words are the ones that were already there, with the punctuation that was holding them together taken out of the way.

• JSON can be pasted directly, pulled from the clipboard in one step, or loaded from a file saved as .json or .txt.
• The readable version redraws automatically about half a second after typing stops, or on demand at any time.
• Any heading or paragraph in the result can be edited directly, in place, by clicking it and typing over the wording.
• The result can be taken away in whatever form is needed: plain text, Markdown, PDF, or JSON again.

Five rules do the work of making it readable, and all five can be adjusted under Settings:

• Titles become titles. Any field whose name contains title or subject, such as Post title or article_subject, is treated as a heading and begins a new section, rather than being printed as one more line of text among the rest.
• Groups become sections. Where information is bundled together, that bundle becomes its own sub-section, and its name is tidied into ordinary words: product_details reads as Product Details, and itemWeight reads as Item Weight.
• Simple lists become bullet points rather than a row of quoted words separated by commas.
• Repeated items become cards. A set of products, competitors, or people becomes one labelled block each, named from the item itself wherever it carries a name, so the result reads Acme and Globex rather than Item 1 and Item 2.
• Formatting marks are honoured. Writers and AI tools leave marks like asterisks around bold text and hashes in front of headings. These are shown as real bold text and real headings instead of as stray punctuation.

JSON breaks easily. One bracket missing off the end, or a stray sentence pasted in front of it, and nothing will open it at all. When that happens, a panel appears describing what is wrong and listing exactly what a repair would change: text pasted before or after the JSON taken out, a sentence that stops halfway closed off, a spare comma dropped, missing closing brackets added. Nothing is changed until a choice is made: applying the repair fixes it and shows the result, previewing it fixes it and waits so the result can be checked first, and dismissing it leaves everything as it was. This is what rescues a download that stopped early or an answer from an AI tool that ran out of room mid sentence.

Anything in the result can be rewritten in place. A changed value is marked as edited, and every export from that point on works from the edited version rather than the original, so what gets copied and what gets saved is the wording that was settled on.

• Copying the full result puts the whole thing on the clipboard with its formatting intact, ready to paste into an email, a document, or a chat box. Headings arrive as headings, tables as real tables with their borders, and bullet points, numbered lists, links, bold and italic all come through as themselves rather than as punctuation. Anywhere that accepts plain text only, such as a code editor or a terminal, receives the plain reading of the same content, with the address behind each link written out in brackets after it. Fonts and colours are left behind on purpose, so what gets pasted picks up the styling of the document it lands in.
• Field name formatting under Output in Settings controls how keys read, both on screen and in everything copied or saved. Replacing underscores and hyphens with spaces also splits a camelCase run, so page_title and pageTitle both read as page title. Field name case then sets the casing: as written leaves it alone, and lower, UPPER, Sentence, and Title are applied on top of the separator setting, so page_title becomes PAGE TITLE with separators replaced and upper case chosen. Title Case leaves short joining words such as of, and, or the in lower case unless they open the name. The keys inside a saved JSON file are never rewritten by this setting, since those are data being written back, not labels being presented.
• A per-field copy control copies one field alone, which is the quicker route when only one paragraph, one table, or one heading is needed rather than the lot. Whether it carries formatting is set under Output in Settings: formatted text keeps headings, bold, links, and list structure where the destination understands them, and plain text puts the plain reading alone on the clipboard, which is what to choose when pasting into a rich editor that would otherwise pick up styling that was not wanted. The choice applies to the per-field copy only, so copying the full result stays formatted and copying as Markdown stays Markdown.
• Copying as Markdown puts the Markdown syntax itself on the clipboard rather than the formatting, so what lands is # headings, **bold**, and - bullets as characters that can be read and edited. This is the one to use for anything that expects Markdown as text: a pull request description, a wiki edit box, a static site source file, or a chat client that renders Markdown itself. Copying the full result is the one to use where the destination understands formatting; this is the one to use where it understands Markdown. The content matches saving as Markdown exactly, including any edits made in the output, so the choice between them is only whether it arrives on the clipboard or as a file.
• Saving as plain text writes a .txt file with headings underlined, sections indented, and every field label sitting on its own line above its value. This is the one to send to somebody who should not have to know what JSON is.
• Saving as Markdown writes a .md file that turns the structure into headings: the title becomes the top heading, each group below it becomes a smaller heading, and so on down. It drops straight into a wiki, a README, or any site builder that reads Markdown.
• Saving as JSON hands back the original file with the edits written into it and everything else untouched, so it can go back to whatever program expects it. Numbers stay numbers and true or false stays true or false.
• Saving as PDF opens the browser's print window with the copy buttons and edit marks taken out, and with page breaks kept out of the middle of tables and paragraphs, ready to save to PDF from there. The page cannot write a PDF file directly, so this is the route to one, and if the browser blocks the print window a ready-to-print file downloads instead.

Settings holds the details: which field names count as titles, which are used to name cards, whether formatting marks are honoured, whether editing is on, and how far to indent saved JSON. That last one takes a whole number from 0 to 8, and also understands 1.5 or 3/2, either of which becomes 1. Text, settings, and edits are remembered in the browser between visits and never leave the machine. Resetting clears the lot.

JSON was designed for programs to read, not people. The awkward part is that the text inside it is very often written for people: a blog post, a product description, a research summary, a set of instructions. Somebody has to check that writing, approve it, or pass it on, and doing that through a wall of brackets and quote marks is slow and error prone. Turning it back into a readable document is the whole point, and these are the moments that call for it.

• Reading what an AI tool gave you: paste the raw answer from ChatGPT, Claude, or an automation that calls one, and read the article the way it will actually appear instead of hunting for it between the quote marks.
• Rescuing an answer that stopped early: a response cut off mid sentence leaves brackets hanging open and nothing will read the file. The repair closes it up and shows everything that did arrive, so a long run that failed at the end is still worth something.
• Checking work before it goes live: step through a batch of generated posts and confirm each one has a title, that no section came back empty, and that the bold and the headings show as formatting rather than as stray asterisks.
• Handing writing to somebody else: a writer or editor should not need a developer to read their own copy. Save as plain text or PDF and send a document, not a data file.
• Client and manager approval: Save as PDF produces a clean paginated document with none of the tooling in it, which is a far better thing to attach to an email than a screenshot of a text editor.
• Comparing a set of things: a summary covering several competitors, products, or suppliers becomes one labelled card each, named after the thing itself, so the comparison reads straight down the page.
• Publishing to a wiki or site: export as Markdown and the structure arrives as real headings in a README, a wiki page, or a static site, instead of as a code block nobody reads.
• Making sense of an export: a file exported from a shop, a booking system, or a survey tool opens as labelled sections with the field names spelled out in words, which is usually enough to find the one value that was being looked for.
• Spotting what is missing: because every field is labelled and every group is indented, a value sitting at the wrong level or a record shaped differently from the rest stands out at a glance.
• Fixing wording without touching code: correct a headline or trim a paragraph in the readable view, then save as JSON to hand the corrected file back to whoever needs it in its original form.