File conversion for developers

Format conversions developers run into in real workflows — config files, data interchange, fonts, and assets.

Developers run into format conversion in surprising places: YAML config files that need to become JSON for an API, CSV exports that need to become a database import, fonts that need to be web-deployed, screenshots that need to become favicons. Most of these aren't really 'developer' tasks — they're side quests that block the actual work. The right tooling makes them disappear.

This page collects the conversions and guides that come up most for developers: config and data formats, web deployment assets, and the gotchas that bite when you're moving data between systems.

Recommended converters for developers

The conversions that come up most in developers' workflows, with a quick note on when to use each.

What format decisions matter most for developers

Developers run into format conversion as a side quest that blocks the actual work: a YAML config that needs to become JSON for an API call, a CSV export that needs to become a database import, an HTML report that needs to become a PDF. Most of these aren't really 'developer' tasks — they're plumbing between systems that don't speak the same format natively.

Format choice often comes down to who's editing it. Humans edit YAML and TOML; machines exchange JSON; legacy enterprise systems demand XML. Use the format that matches the writer at each boundary. Don't make humans edit raw JSON, and don't make API parsers handle YAML's ambiguity.

Parser strictness varies wildly between formats. JSON is strict and predictable. YAML 1.1 has the famous Norway problem (`NO` parses as boolean false) and quietly coerces strings that look like numbers. CSV doesn't standardize escaping or encoding. Pick a format whose parser behavior matches your tolerance for surprise.

Developers workflow recommendations

The format and conversion choices that consistently produce the best results for developers.

  1. Use YAML for human-edited config, JSON for machine-to-machine

    Kubernetes, GitHub Actions, Docker Compose — these all use YAML because humans edit them. APIs use JSON because parsers are faster and more strict. Convert at the boundary, not in the middle.

  2. Quote string values that look like other types in YAML

    Unquoted 'NO', 'yes', '01234' get coerced to boolean/number in YAML 1.1 (the famous 'Norway problem'). Quote any string that could be misinterpreted, or use a YAML 1.2 parser.

  3. UTF-8 with BOM for CSV-to-Excel

    Excel detects UTF-8 only when there's a BOM at the start. Without it, accented characters and non-Latin scripts display as garbled. Add the BOM at write time, not in a downstream cleanup.

  4. Subset web fonts to characters you actually use

    A font shipped to the browser with full Unicode coverage is 5-10× larger than one subset to your site's actual character set. Subsetting before converting to WOFF2 produces dramatically smaller files.

Common mistakes developers make with file formats

The pitfalls that come up repeatedly for developers — most of them invisible until they cause an audible, visible, or workflow problem downstream.

  • Forgetting BOMs when handing CSV to Excel

    Excel detects UTF-8 in CSV only when there's a BOM at the start of the file. Without it, accented characters and non-Latin scripts display as garbled. Add the BOM at write time, not in a downstream cleanup step.

  • YAML 1.1 Norway problem

    Country code 'NO' parses as boolean false in YAML 1.1. So does 'NULL', 'null', 'YES', 'On', 'Off', and version strings like '1.0'. Always quote strings that could be misinterpreted, or use a YAML 1.2 parser explicitly.

  • Subset web fonts AFTER conversion to WOFF2

    If you subset a TTF to your actual character set THEN convert to WOFF2, you get a WOFF2 of the subset (5-10× smaller). If you convert THEN try to subset, the subsetting tool may not understand WOFF2 and you ship the full font.

  • JSON-LD schema invalid because dates aren't ISO 8601

    Schema.org JSON-LD requires ISO 8601 dates (`2026-05-03T15:42:00Z`). JavaScript's `new Date().toString()` gives you `Sat May 03 2026 15:42:00 GMT-0400` — invalid for schema purposes. Always use `toISOString()`.

Frequently asked questions

When should I use YAML vs JSON?

YAML when humans edit the file (config, IaC, GitHub Actions). JSON when machines exchange the data (APIs, log streams, machine-to-machine RPC). Convert at the boundary if you have to — don't make either side handle the wrong format.

Is converting CSV to XLSX worth doing?

When non-technical stakeholders consume the data, yes. CSV opens fine in Excel but loses leading zeros, dates auto-coerce wrong, and large files chug. XLSX preserves types, handles formatting, and supports multiple sheets. Convert when handing data off; keep CSV when piping into databases or BI tools.

What's the right way to render HTML reports as PDF?

Headless Chrome with Puppeteer or Playwright is the strongest production option — it renders exactly what a browser shows. wkhtmltopdf is older and rendering can drift from current HTML/CSS standards. Print-specific CSS (`@media print`, `@page`) makes a huge difference in the final PDF quality.

Why does my XML-to-JSON conversion lose attributes?

JSON has no concept of element attributes vs. content — both become object keys. Conversion libraries pick conventions (often prefixing attributes with `@` or `_` or putting them under a `$` key). Test your downstream parser; if it expects a specific convention, configure your converter to match.

Should I version-control binary asset formats?

Use Git LFS for large binary formats (PSD, AI, video, large PNG/JPG, audio). Plain Git treats every save as a new full copy, blowing up repo size. LFS stores the binary out-of-band and keeps Git's metadata light. Set up `.gitattributes` to route the right extensions through LFS automatically.

Recommended reading

In-depth guides relevant to developers' format decisions.

Ready to convert?

Free, instant, no signup. Files deleted within an hour of upload.

Open the converter