Browse tools
Free · Fast · Privacy-first

JSON to CSV With Windows Line Endings

Line endings in CSV are a small detail that matters a lot to some downstream tools.

Native JSON tool

JSON to CSV

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

CRLF by default per RFC 4180

🔒

Optional LF for Unix pipelines

✨

Maximum tool compatibility

⚡

Free, browser-based

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 line endings still matter in CSV

Line endings are an inherited quirk from the era when teletypes used CR to return the carriage and LF to advance the paper. Modern OSes settled on different conventions: Windows kept CRLF, Unix uses LF, and classic Mac OS used CR. CSV inherited the Windows convention as the spec-recommended default because the format was widely used in business contexts where Windows dominated. RFC 4180 explicitly specifies CRLF.

Most modern tools handle both CRLF and LF gracefully on input. Excel 2016+ accepts both, Sheets accepts both, every modern parser accepts both. But older tools and some integration endpoints still insist on CRLF, and a CSV with LF-only line endings can fail to parse correctly in those environments. The safe default for unknown downstream is CRLF.

Unix-native pipelines tend to prefer LF. Tools like cut, awk, and sort handle LF natively; CRLF files can confuse line-oriented tools because the CR remains attached to the previous line's data. For pipelines you control on Linux or macOS, switching to LF avoids the need for dos2unix preprocessing.

Mixed line endings within a single file are the worst case: some lines CRLF, others LF. This happens when CSVs are edited in tools that do not normalise on save. The result is unpredictable parser behaviour. FixTools always produces uniform line endings across the whole file, so the output is consistent regardless of input quirks.

RFC 4180 line ending ruleNewline conventions across operating systems

How to use this tool

💡

Produce CSV with CRLF (Windows) line endings by default for maximum compatibility. Switch to LF for Unix-native pipelines.

How It Works

Step-by-step guide to json to csv with windows line endings:

  1. 1

    Paste JSON

    Paste your JSON.

  2. 2

    Confirm CRLF setting

    CRLF is the default and the right choice for Windows tools, Excel, and unknown downstream. Switch to LF for Unix pipelines.

  3. 3

    Download

    Download the CSV. Line endings are uniform across the file per your selection.

  4. 4

    Verify if uncertain

    On macOS or Linux, run xxd file.csv | head to inspect the byte structure. CRLF shows as 0D 0A at line ends; LF shows as 0A only.

Real-world examples

Common situations where this approach makes a real difference:

Legacy ETL ingestion

A legacy Windows-based ETL pipeline requires CRLF line endings. The converter's CRLF default produces files the pipeline ingests on first attempt.

Excel on older Windows

An Excel version from a decade ago refuses to recognise row breaks in LF-only CSVs. CRLF resolves the issue.

Unix awk pipeline

A Unix awk pipeline expects LF. The converter's LF option produces files awk handles natively without dos2unix preprocessing.

Regulatory submission

A regulator requires CRLF per the submission specification. The default produces compliant files.

Pro tips

Get better results with these expert suggestions:

1

Default CRLF unless you know better

For unknown downstream consumers, CRLF is the safer default because it matches RFC 4180 and works on every modern tool. Switch to LF only when you know the downstream is Unix-native.

2

Use dos2unix to convert after download

If you forgot and downloaded with CRLF but need LF, run dos2unix file.csv to convert in-place. Or vice versa with unix2dos.

3

Watch for line ending mismatches in pipelines

A pipeline that produces CRLF files but is consumed by an LF-only tool will fail mysteriously. Always confirm line endings match the consumer expectation.

4

Avoid editing CSVs in tools that change endings

Some text editors silently convert line endings on save. If you must edit a CSV, use a tool that preserves line endings (vim with explicit fileformat settings, VS Code with explicit EOL configuration).

FAQ

Frequently asked questions

Carriage return plus line feed (\r\n). The Windows-style line ending and the RFC 4180 default for CSV files. Mandated by the spec for maximum compatibility.
Some older tools and legacy pipelines require CRLF and break on LF-only files. CRLF is the safe default for unknown downstream consumers. Modern tools usually accept both.
When the downstream is a Unix-native pipeline (awk, cut, sort) or a Linux/macOS-specific tool. LF avoids the need for dos2unix preprocessing in those environments.
Yes. Excel, Sheets, Numbers, and every major data tool handle CRLF correctly on input. There is no compatibility issue from including CRLF for any modern consumer.
On macOS or Linux, run file your-file.csv (reports CRLF in the output) or xxd your-file.csv | head (shows 0D 0A for CRLF, 0A for LF at line ends). On Windows, use Notepad++ to see the encoding and line-ending mode in the status bar.
Yes. dos2unix file.csv converts CRLF to LF. unix2dos file.csv converts LF to CRLF. Both are standard tools on macOS and Linux and available for Windows via WSL or Cygwin.
Classic Mac OS (pre-OS X) used CR-only line endings. Modern macOS uses LF. CR-only is virtually extinct and not supported by FixTools as an option because no modern downstream consumer requires it.

Related guides

More use-case guides for the same tool:

JSON to CSV for Excel
JSON to CSV Utf8
Convert JSON to CSV

Related tools

Other tools you might find useful:

{ }

JSON Formatter

Format the JSON first.

⇄

CSV to JSON

Reverse direction.

≠

Diff Checker

Compare two CSVs after export.

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

JSON authority hub

Validate → diagnose → repair → model → transform

Move through the JSON problem with connected tools and references instead of treating formatting, parser errors, schema checks and API debugging as unrelated jobs.

Diagnose JSON
Find syntax errors and the parser position.
Fix Invalid JSON
Repair common malformed JSON problems.
JSON Validator
Check strict JSON syntax in your browser.
Schema Validator
Check valid JSON against expected structure and constraints.
Error Encyclopedia
Look up parser errors with broken and fixed examples.
Developer utilities
JSON FormatterJSON Diff & CompareFlatten / UnflattenEscape / UnescapeJSON SorterJSON to TypeScriptJSONPath Tester
JSON references & parser guides
JSON Schema GuidePointer vs JSONPathJSON5 vs JSONJSONCNDJSON / JSON LinesDebug API JSONJavaScript JSON.parsePython JSONDecodeErrorGo json.Unmarshal

Source-backed reference

JSON standards quick reference

Concise, standards-backed facts for developers working with JSON debugging and validation. Each claim is linked to the evidence registry and resolves to a primary standard or platform reference so it can be independently verified.

JSON standard
JSON is a text format for serializing structured data, with syntax defined by interoperable standards rather than by FixTools.
Verify with IETF / RFC Editor →Verify with Ecma International →
Strings and object keys
JSON strings and object member names use double quotation marks. Single-quoted strings are not valid standard JSON syntax.
Verify with IETF / RFC Editor →
Trailing commas
Standard JSON grammar does not allow a comma after the final member of an object or the final element of an array.
Verify with IETF / RFC Editor →
Parser behavior
JSON.parse() parses JSON text into a JavaScript value and raises a SyntaxError when the input is not valid JSON.
Verify with MDN Web Docs →

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 source-specific evidence. This keeps technical claims independently verifiable and gives search and answer systems a clearer provenance trail than unsupported summary copy.