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.

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:

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.