Free · Fast · Privacy-first

JSON to CSV UTF-8

JSON is UTF-8 by spec.

Native JSON tool

JSON to CSV

Runs in your browser
CSV output
Run the tool to see a task-specific result.

UTF-8 encoding by default

🔒

Optional BOM for Windows Excel

Preserves international characters

Handles emoji and special symbols

Cost
Free tier
Sign-up
Not required
Processing
Tool-specific
Privacy
Clearly disclosed
IframeResponsiveAttribution included

Add this JSON to CSV to your website

Drop the JSON to CSV into a blog post, product docs, intranet, or school portal with one iframe. Processing, privacy, and usage limits are the same as on the full tool page.

  • One copy-ready line of HTML
  • Responsive — adapts to any container width
  • No API credentials are placed in the snippet

Embed code

<iframe
  src="https://www.fixtools.io/json/json-to-csv?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="JSON to CSV by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

Attribution-friendly: a small "Powered by FixTools" link appears in the embed footer.

Why UTF-8 is the right default for CSV

UTF-8 is the universal encoding of the modern web. RFC 8259 defines JSON as UTF-8, and every modern JSON parser produces UTF-8 strings on parse. The natural CSV output to match is UTF-8 because any other encoding would require lossy or escape-heavy transcoding of values. FixTools writes UTF-8 directly, which means every character that can be represented in your source JSON is preserved exactly in the CSV.

The BOM (byte-order mark) is a three-byte signature (EF BB BF) at the start of a UTF-8 file that signals the encoding to readers. Excel on Windows uses the BOM to detect UTF-8 reliably; without it, Excel falls back to the system code page and mangles accented characters. macOS Excel, Google Sheets, Apple Numbers, and most text editors handle UTF-8 with or without BOM. The default in FixTools is BOM-on, which is the safe choice for Windows-Excel-bound files. Switch to BOM-off for Unix pipelines where the BOM is sometimes treated as part of the first field.

Emoji and other supplementary-plane Unicode characters (those above U+FFFF, encoded as surrogate pairs in UTF-16) work correctly because UTF-8 represents them as four-byte sequences without any special escaping. A row containing a customer name with an emoji icon (some forms allow them now) preserves the emoji exactly in the CSV.

Common encoding traps in non-UTF-8 contexts include Windows-1252 (the default code page for older Windows systems), ISO-8859-1 (the historical Latin-1 encoding), and Shift_JIS (the Japanese Windows code page). Files written in those encodings render correctly only on systems with matching locale settings, which is why UTF-8 is genuinely better as a portable encoding. If a downstream tool absolutely requires a non-UTF-8 encoding, transcode the CSV after download using iconv or a similar tool.

How to use this tool

💡

Output UTF-8 CSV with optional BOM. Preserves all Unicode characters from the source JSON including accents and emoji.

How It Works

Step-by-step guide to json to csv utf-8:

  1. 1

    Paste JSON

    Paste JSON containing any Unicode characters.

  2. 2

    Confirm UTF-8 BOM setting

    BOM on for Windows Excel compatibility. BOM off for Unix pipelines.

  3. 3

    Download

    Download the file. Unicode characters in your data travel through correctly.

  4. 4

    Verify in spreadsheet

    Open the CSV in your spreadsheet and confirm international characters render correctly.

Real-world examples

Common situations where this approach makes a real difference:

International customer list

A SaaS company exports customer JSON with names from many countries (José, Müller, 田中). UTF-8 with BOM produces a CSV that renders all names correctly in Excel on Windows.

Product names with currency

A retail export has product names with currency symbols (€, £, ¥). UTF-8 preserves them through the CSV without escape sequences.

User-generated content with emoji

A social platform exports user posts as JSON with emoji content. UTF-8 carries the emoji into the CSV intact.

Multilingual survey data

A global survey produces JSON with responses in many scripts (Arabic, Hebrew, Cyrillic, CJK). UTF-8 preserves every script faithfully.

Pro tips

Get better results with these expert suggestions:

1

Always BOM-on for Windows Excel users

If your recipient might be on Windows Excel, BOM-on is the safe default. macOS Excel and Google Sheets tolerate the BOM, so there is no downside to including it for mixed audiences.

2

BOM-off for Unix pipelines

Tools like cut, awk, and sort that read line-by-line may treat the BOM as part of the first field. For Unix-only consumers, BOM-off is cleaner.

3

Verify with a hex dump if encoding is suspect

If you doubt the encoding, run xxd file.csv | head on the file. UTF-8 with BOM starts with EF BB BF. UTF-8 without BOM starts with the first character's bytes directly. Other encodings show different byte patterns.

4

Transcode if downstream needs non-UTF-8

For rare legacy consumers requiring Windows-1252 or another code page, transcode after download with iconv -f utf-8 -t windows-1252 file.csv > file-1252.csv. Some characters may be lost in transcoding.

FAQ

Frequently asked questions

UTF-8, the universal modern encoding. UTF-8 preserves all characters from the source JSON without information loss, including accents, currency symbols, emoji, and non-Latin scripts.
Yes if your recipient might open the file in Excel on Windows. The BOM signals UTF-8 to Excel and prevents character mangling. macOS Excel and Google Sheets tolerate the BOM, so it is safe to include for mixed audiences.
A three-byte signature (EF BB BF) at the start of a UTF-8 file. The bytes signal the encoding to readers. The BOM is invisible to humans because it does not represent a printable character, but it is meaningful to parsers.
Yes. UTF-8 represents supplementary-plane Unicode (including emoji) as four-byte sequences. No special escaping is needed; the emoji travel through the conversion intact.
Transcode after download using iconv or a similar tool. Note that Latin-1 cannot represent characters outside its limited set, so any non-Latin characters in the data will be lost or replaced.
Yes. On macOS or Linux, run file -i your-file.csv. The output indicates the encoding. For UTF-8 with BOM, the file command reports utf-8 with charset notation.
Modern spreadsheet apps handle UTF-8 well: Excel (Windows and Mac), Google Sheets, Apple Numbers, LibreOffice Calc, OnlyOffice. Excel on Windows specifically benefits from the BOM; others handle either form.

Related guides

More use-case guides for the same tool:

Ready to get started?

Open JSON to CSV to review its free limits and processing method.

Open JSON to CSV →

Free tier · No account needed · Transparent limits

Source-backed reference

JSON standards quick reference

Concise, standards-backed facts for developers working with JSON debugging and validation. Each rule links to a primary specification so it can be independently verified before you rely on it in code, documentation, or an incident report.

JSON standard
RFC 8259 defines JSON as a text format for serializing structured data. JSON values may be objects, arrays, strings, numbers, true, false, or null.
Verify in RFC 8259
Strings and object keys
JSON strings and object member names use double quotation marks. Single-quoted strings are not valid JSON syntax.
Verify in RFC 8259 §7
Trailing commas
The JSON grammar does not allow a comma after the final member of an object or the final element of an array.
Verify in RFC 8259 §4–5
Interoperability
ECMA-404 describes the JSON syntax independently of any programming language, which is why standard parsers can exchange the same JSON text across runtimes.
Verify in ECMA-404

Common invalid → valid JSON examples

Trailing comma

{"a":1,}{"a":1}

Single-quoted key

{'a':1}{"a":1}

Unsupported literal

{"score":NaN}{"score":null}

Built for verification, not just extraction

Direct answers are paired with primary sources and concrete examples. That makes this page useful to developers and also gives search and answer systems a clear, verifiable statement to reference instead of an unsupported summary.