PasteCleanlyIn this guide
- Decide what the destination needs
- Check JSON syntax before reading the data
- Choose readable formatting or compact output
- Separate syntax checks from schema checks
- Convert a small CSV sample before the full export
- Make a separate table for documentation
- Escape text for HTML in the right context
- Decode one layer and check what changed
- Walk through a realistic two-row handoff
- Verify each output in its receiving application
Decide what the destination needs
One export can have several useful representations. A program may need JSON objects with known keys. A project README may need a short Markdown table. An HTML example may need to display an ampersand or angle brackets without the browser reading them as markup. Pick the destination first. A table that looks right in a browser is not necessarily a reliable source for importing records back into a program.
Keep one original with a known delimiter or documented structure. For example, a small team might have a CSV with ticket_id, summary and status. Make the machine-readable JSON and the presentation table from that CSV separately. Don't take the rendered table, copy it back to the clipboard and use it as the next source of truth. Empty values, leading zeros and line breaks are easy to lose in that round trip.
Decide what should stay exact. If an identifier has five digits including its leading zeros, note that it is text even though it looks like a number. If a note may include a line break, preserve it in the original and choose how to display it separately. Test with a few representative records before converting the full source.
Check JSON syntax before reading the data
Valid JSON uses double quotes for property names and string values. It does not allow comments, trailing commas or a placeholder like undefined. A list begins with a bracket; an object begins with a brace. Paste just the data, not the Markdown code fence around an example or an assignment such as const config =. JavaScript object notation and JSON look similar, but many things valid in a JavaScript file are not valid in JSON.
{ "ticket_id": "00123", "open": true, "note": null }Start with a small valid example so you can tell whether the error is in your source or in how it was copied. If the formatter reports a parse error, look at the indicated area and the value before it. A missing closing quote may cause the error to be detected later than the character you actually need to fix. Curly quotes pasted from a document are text characters, not JSON string delimiters.
Repair one error at a time and run the check again. Avoid globally replacing quotation marks: a quote inside a correctly escaped string is part of the value and should not be changed.
Choose readable formatting or compact output
Indentation helps a person see where each record or nested value begins and ends. Use pretty formatting when reviewing a sample, comparing two versions or putting a small object in documentation. Pick two or four spaces based on the conventions of the receiving project. Use minify when you need a compact representation and the consumer will parse it anyway. Minifying is not compression, encryption or a way to hide data.
The formatter validates the text and then changes whitespace outside JSON tokens. It does not recreate the result by converting every number into a JavaScript number and writing it back. For example, the characters in 9007199254740993, 1e-7 and -0 can stay as written. An escape inside a string stays an escape in the output. This is useful when formatting an export without silently changing how a value was written.
That preservation does not make a receiving system capable of storing every number exactly. If an identifier can exceed a system's safe integer range, agree on representing it as a string before exporting. Inspect the actual imported value, especially when another application might coerce it to a number.
Separate syntax checks from schema checks
A syntax check confirms that a JSON parser can read the text. It does not confirm that an API or importer will accept it. For example, both {"ticket_id":"00123"} and {"ticket_id":123} are valid JSON. Only the string preserves that exact code. Likewise, an object and a list of objects can both be valid even though an importer may accept only one of those shapes.
Check the receiving application's expected field names, types and required fields. Pay attention to null, an empty string and a missing property. Those can all mean different things. If the app has an example import, start with that shape. Then add one representative value from your data and test it. When possible, use a test environment or the app's import preview before changing live records.
Look for repeated keys within an object. A formatter that preserves source tokens does not deduplicate them, and systems can disagree about which value to use. If the same property appears twice, correct the source to express the intended value once. A pretty output with no syntax error is still not evidence that business rules or uniqueness constraints passed.
Convert a small CSV sample before the full export
Open the CSV and JSON converter with a header and two or three rows. Check whether the first row is intended to supply object keys. With no header, an array of fields may be a better representation. If two headers repeat, rename them deliberately instead of expecting two same-named object properties to identify two separate columns. Keep a mapping if the import requires standardized field names.
ticket_id,summary,status 00123,"Cable, bracket & stand",open 00124,"Label says <ready>",closed
The quotes protect the comma in the first summary. The ampersand and angle brackets are literal CSV content. They don't need HTML entities in the CSV or JSON version merely because someone might later view them on a web page. Apply HTML escaping only when producing a version for that context. Check that the JSON still contains the exact same summaries and that the ticket IDs are strings with their initial zeros.
For a table with multiline fields or semicolon delimiters, follow the list and table guide to check the parsing. A field should not move columns just because it contains punctuation or a line break.
Make a separate table for documentation
When people only need to see a few records, generate a Markdown table directly from the CSV. Choose the right delimiter, confirm the header setting and preview the result in the actual destination. If the summary includes a pipe, the converter escapes it so it can remain inside the cell instead of acting as a column boundary. If the input includes literal angle brackets, the generated table represents them as text instead of embedding the original tag-looking value as markup.
Limit a documentation example to the columns that matter. If you are showing a naming convention, you may need the ticket identifier and summary but not a large internal note. Use synthetic examples when the source contains personal or confidential information. The utility works locally, but copying a result into a public ticket or repository is a different action with a different audience.
Markdown table rendering is not identical everywhere. Preview a row with an escaped pipe, a cell containing a line break and a very long value. Some renderers do not support tables or may suppress embedded breaks. If that happens, use a short list or a separate file instead of assuming the raw table source will always look good.
Escape text for HTML in the right context
HTML uses angle brackets to mark tags and ampersands to begin character references. If you are writing HTML source and want to show the literal text Bag & box <ready>, escape those characters for a text node. That lets a browser display the text instead of treating <ready> as markup. An ampersand already used as part of an entity must not be accidentally encoded a second time unless you intend to show the reference itself.
Input: Bag & box <ready> Output: Bag & box <ready>
Use the tool on the literal value, not on a complete page you want to keep functional. Escaping an entire page converts the tags into visible text. For a template or an application, prefer its own context-aware escaping or a text-only binding. A value inserted into an HTML text node, a URL, an attribute or a script does not necessarily use the same rules.
The encoder is not an HTML sanitizer. It does not make an arbitrary template, link or script safe. If you only want to display plain text in an editor, you usually don't need to encode it at all. Use escaping because the destination requires it, not because the original contains punctuation.
Decode one layer and check what changed
Sometimes a note arrives as Bag & box even though you need to display it as ordinary text. Choose decode and inspect the output before applying it to the input. One pass turns a recognized reference into a character; it does not repeatedly decode until the result stops changing. That behavior matters when a reference appears in a teaching example and should be visible rather than interpreted.
For example, a string containing &lt; becomes the literal reference < after one decode, and a less-than sign after another. Decide which representation is expected by the next program before running a second pass. If the source is HTML, ask whether you need the page's visible text or just the decoded source. Decoding references will not remove tags or extract the text from a layout.
HTML references and URL encoding serve different purposes. The characters %26 encode an ampersand in a URL component; & represents it in HTML source. If you are troubleshooting a copied URL parameter, use the URL component decoder on the value rather than applying HTML decoding to every percent sign.
Walk through a realistic two-row handoff
Take the two tickets above and save the CSV unchanged. For a machine import, convert the header and rows into JSON objects. Pretty-print the result so you can inspect the keys and the two identifiers. Compare the summary for the first ticket with the CSV: the comma and ampersand should still be there. Review the second summary and confirm that the angle brackets remain part of the string, not a tag from a template. Use the import preview to confirm what the receiving system sees.
For the review ticket, make a Markdown table directly from the same CSV, and render it in the destination. The output is meant for someone to read, so remove unnecessary columns only in that presentation copy. If you also need an HTML code example that displays a summary, encode just the sample value for HTML. Do not replace the stored summary with the encoded version.
When a colleague asks which version to reuse, point to the unchanged source or the agreed machine-readable export. Label the presentation copy separately. This small distinction prevents the table copied from a documentation page from becoming the next data import without anyone realizing that it dropped fields.
Verify each output in its receiving application
Before sharing, check the first and last record and one tricky value in the middle. For JSON, validate syntax, then check the expected fields and value types in the importer. For Markdown, preview the actual page and inspect the header, alignment and any punctuation that resembles syntax. For HTML, check both the source and what appears in the browser. These are different checks; a passing result in one format says little about the others.
If one version fails, go back to the saved source and isolate the smallest record that reproduces the problem. Then decide whether the source is malformed, the conversion setting is wrong or the destination interprets the result differently than expected. Avoid repeatedly converting the full file while changing multiple settings at once. It makes it hard to tell which change fixed the issue, and it can hide a separate loss of data.
Keep a miniature input and the expected result as a reference for the next export. Include a leading-zero identifier, an empty field and some punctuation. A good three-row example makes it easier to update a pipeline later without guessing what was supposed to happen to the unusual rows.