File Converter: Two Unrelated Jobs, One Tool

This tool does two jobs that don't share much code in common but share everything about why they belong in the same place: converting image formats (PNG, JPG, WebP, BMP, ICO, GIF, TIFF, SVG, AVIF) and converting structured text formats (CSV, TSV, JSON, YAML, XML, Markdown, HTML, plain text, Base64). An image codec and a JSON-to-YAML transformer have nothing to do with each other technically. What they have in common is that they're both "I have a file, I need it in a different format, right now, without installing anything," which is a real, frequent need that doesn't care that the underlying conversions are unrelated.

Detecting the file type has to come before anything else

The moment you drop a file in, the tool has to figure out what it actually is before it can offer any conversion options at all, and trusting a file's extension alone isn't reliable enough — extensions get changed, stripped, or are just wrong. The tool inspects the actual file content, not just its name, to decide what family it belongs to before showing you a single output option. Getting this step wrong in either direction is bad: too permissive and you offer conversions that will just fail or produce garbage output; too strict and you reject a perfectly convertible file because its extension didn't match what the content-sniffing expected.

Only showing conversions that actually make sense

Once the file type is known, the "convert to" grid only shows targets that are genuinely valid for that source — a CSV file doesn't get offered a PNG output, an image doesn't get offered YAML. That sounds obvious written down, but the lazy version of this tool would just show every supported format all the time and let a doomed conversion attempt fail with an error afterward. Filtering the options up front instead of failing gracefully afterward is a small UX decision that removes an entire category of confusing dead-end clicks, and it meant building an explicit compatibility map between every source type and its valid targets rather than assuming any format can theoretically become any other format.

The data-format conversions are the trickier half

Image format conversion is mostly a solved problem — decode into raw pixel data, re-encode into the target container format, done. The structured-data conversions are messier, because formats like CSV, JSON, YAML, and XML don't all model data the same way. JSON and YAML map onto each other almost directly since they're both describing the same kind of nested structure. CSV is flat and tabular by nature, so converting a deeply nested JSON object into CSV means making a real decision about how to flatten it, and that decision changes what "correct" even means for the output. There isn't one universally right answer, so the converter makes a reasonable, consistent choice and stays predictable about it rather than trying to be clever about every possible input shape.

Not every browser agrees on what it can encode

AVIF support is the specific thing that made me actually test across multiple browsers instead of just building against whatever I had open. Decoding AVIF to preview it is one thing; encoding to AVIF as an output format depends on what the browser's own image pipeline actually supports, and that support isn't uniform. A conversion that works perfectly in one browser can silently fail or fall back to something unexpected in another, and the failure mode is worse than an error message — it's a "successful" conversion that produced a broken or wrong file. I ended up feature-detecting actual encode support at runtime rather than assuming it based on browser name or version, since trusting a user-agent string to predict codec support is exactly the kind of fragile assumption that breaks the first time a browser updates its capabilities without changing how it identifies itself.

Paste-to-convert turned out to matter more than drag-and-drop

Supporting Ctrl+V to paste a file directly, instead of only accepting a drag-and-drop or a file browser click, wasn't something I planned around up front — I added it once I noticed how often I personally wanted to convert something I'd just copied rather than something sitting in a folder I'd have to navigate to. For a quick one-off conversion, browsing to a file on disk is real friction compared to copying it and pasting it straight in. It's a small addition that came from using my own tool more than from planning its feature list on paper, which is turning into a fairly reliable way to find the features actually worth building.

This is also the tool on the site I'd bet gets the widest range of file sizes thrown at it, from a tiny JSON snippet to a large image, and the entire conversion pipeline has to stay responsive across that whole range without a server to offload the heavier end of it to. That's the same trade-off as everything else built this way — client-side means private, and private means the visitor's own device is doing the actual work, for better and for worse.

I also had to decide what "failure" should look like when a conversion genuinely can't be done cleanly — a CSV with an inconsistent number of columns per row, say, or a JSON structure too irregular to flatten into a sane table. The tool surfaces a clear message about what went wrong rather than silently producing a mangled file, which sounds like an obvious bar to clear until you consider how tempting it is to just attempt a best-effort conversion and let someone discover the problem themselves later, in whatever program they open the result in. A loud, honest failure right at conversion time is worth more than a quiet, broken success.

Base64 is the odd one out in the data-format list, and I nearly left it off — it's not really a "structured data format" the way CSV or YAML are, it's an encoding scheme that happens to turn any file into text. I kept it in because the actual use case is common enough to matter: someone needing to paste an image or a small file into a place that only accepts plain text, like an email body or a config value. It doesn't fit the tool's mental model as cleanly as the rest of the list, but the tool exists to solve real, frequent annoyances, not to stay conceptually tidy, and Base64 conversion is a genuinely frequent annoyance.