Keep formula-looking text literal in a spreadsheet review export

Decide whether the recipient needs text or formulas

A support export includes a customer’s comment, an internal label and a literal calculation example. If the destination is a review spreadsheet, these fields should remain text. If the destination is a calculation workbook you control, some fields may intentionally be formulas. Write that difference down before choosing an export option.

Spreadsheet software may interpret cells beginning with certain characters as formulas. That is a separate layer from CSV syntax. The safe synthetic fixture here uses =1+1 as text; it contains no external link, command or private data. Its expected visible value is the literal expression, not the number 2.

Review fixture as JSON:
[{"kind":"comment","value":"=1+1"},{"kind":"label","value":"+sample"},{"kind":"plain","value":"parcel ready"}]

OWASP: CSV injection and spreadsheet interpretation ↗

Do not confuse cell boundaries with literal text

CSV quotes protect the structure of a cell containing a delimiter or line break. They do not define the spreadsheet’s cell type. Seeing "=1+1" in a text editor therefore does not establish how a spreadsheet will display or calculate the imported cell.

Inspect the export as plain text first. Then use the destination’s documented text-import controls where available. Test in a new disposable document, and avoid evaluating untrusted formulas while investigating a file from another party. Keep the source strings so you can distinguish a protective change from data corruption.

RFC 4180: CSV quoting ↗OWASP: CSV injection and spreadsheet interpretation ↗

Review the explicit protection choice

KitForma JSON to CSV enables its spreadsheet formula protection by default. For the fixture, the first two value cells receive an apostrophe prefix in the exported CSV; parcel ready remains unchanged. The feature also considers headers and leading whitespace when detecting formula-like cells. The exported bytes intentionally differ from the raw strings.

Use this tool to prepare a small candidate export, then inspect it in the actual recipient application. It cannot certify every spreadsheet’s import behavior. If a machine importer requires the original characters, use a separate documented export path that preserves those strings and does not open them as active spreadsheet content.

1. Keep an unchanged copy of the JSON fixture.
2. Convert with formula protection enabled.
3. Inspect the CSV text for intentional prefixes.
4. Import the candidate as text in a disposable spreadsheet.
5. Compare the visible value and underlying cell behavior.

Expected protected cell contents in the CSV:
=1+1      →  '=1+1
+sample   →  '+sample
parcel ready  →  parcel ready

Document the artifact that the next person receives

Give the review export a distinct name and record that formula-like strings were prefixed. Keep it separate from a machine import file. Reopen the saved spreadsheet or re-exported CSV and inspect the three fixture values again; another save step may change how a prefix is retained or interpreted.

For real records, add a review flag or manifest entry for changed fields so a colleague can trace the source value. Do not strip all leading apostrophes from an incoming file: an apostrophe may be genuine data. If the receiving application cannot reliably preserve the intended text, agree on a different delivery format and verify that path.

Q: What about a genuine negative amount?

Decide its type from the data contract. A numeric amount and a text field beginning with a minus sign are different cases. Review any protective prefix and the destination’s numeric import settings so that a safety choice does not silently break calculations.

Q: Does an apostrophe make every CSV safe everywhere?

No universal behavior is claimed here. Import, save and reopening behavior can differ between applications. Use harmless fixtures to verify the exact destination and retain a separate record of the original strings and protection applied.