Choosing the right output format in Novus Convert

A converter’s output menu looks like a preference and behaves like a commitment. Pick JPG for a logo and the crisp edges grow fuzz. Pick PNG for a forty-photo shoot and the folder balloons to five times the size it needed to be. Pick CSV for a deeply nested JSON export and the structure gets steamrolled into columns that no longer mean what the original meant. None of these are bugs — they are formats doing exactly what formats do, which is impose their own assumptions on whatever passes through them.

So when I built Novus Convert, I resisted the temptation to add a “best format” auto-picker, because the best format is a fact about where the file is going, not about the file itself. The same photograph wants WebP on my website, JPG in an email to someone whose software I cannot vouch for, and PNG if it is about to go through five more editing passes. Only the person running the conversion knows the destination, so the interface puts the choice in your hands per file and keeps the routes honest about what they produce.

This guide is the decision layer I run in my own head at the output picker, written down. It covers the image calls — photo versus graphic, transparency, animation — then the structured-data routes where round-trip behavior is the whole game, then archives, then the quality-versus-size dial, and finally why the app refuses to hand over any result that fails validation. The complete route inventory and limits live at Novus Convert; this is about choosing well within them.

Continuous-tone images — photos of people, places, products, anything a camera saw — compress beautifully in lossy formats because the gradual color transitions hide the approximation. For these, my choice is a two-horse race. JPG is the universal donor: every device, every upload portal, every government website, every grandparent’s tablet renders it without a thought, which makes it the automatic pick whenever the file leaves my control. WebP typically lands meaningfully smaller at comparable visual quality, which makes it my pick for anything web-bound where I control the page serving it.

The HEIC pile on every iPhone owner’s hands is the most common real-world version of this call. Apple’s format is technically excellent and socially awkward — half the systems you send it to shrug at it — so the practical move is HEIC to JPG for sharing and HEIC to WebP for publishing, both of which are active local routes in the converter. The same logic covers AVIF sources arriving from newer tools: superb format, patchy reception, convert at the boundary where the file exits your ecosystem.

One JPG behavior is worth knowing before you pick it: the format has no concept of transparency, so when a source with an alpha channel heads to JPG, Novus Convert composites it onto a white background rather than producing something broken. For an actual photograph this is irrelevant, because photographs have no transparent pixels. But it is the canary that tells you a file was never a photograph in the first place — if white corners appear where you expected transparency, you wanted the next section’s formats, not this one’s.

Images made of flat color regions and hard edges — logos, icons, charts, UI screenshots, diagrams — are the opposite compression problem from photos. Lossy encoders smear their sharp boundaries into visible ringing artifacts, and text in a screenshot is the first casualty. These files go to PNG, which compresses flat-color regions efficiently, preserves every pixel exactly, and carries full alpha transparency. A logo that must sit on unknown backgrounds is the canonical case: PNG keeps its transparent surround intact through any number of downstream uses.

WebP complicates the picture in a useful way, because it operates in both worlds — it supports transparency and can encode losslessly while frequently beating PNG on size. For web delivery of graphics I increasingly route to WebP and pocket the savings. The reason PNG still earns its place in my exports is the same reach argument from the photo section inverted: design tools, print shops, slide software, and older pipelines treat PNG as a first-class citizen everywhere, while WebP support outside browsers remains genuinely uneven. Web-bound graphic, WebP; graphic with an unknown future, PNG.

Screenshots deserve their own sentence because people reflexively JPG them and immediately regret it. A screenshot is text and interface chrome — the exact content lossy compression damages most visibly — and the artifact fuzz around every letter is what makes screenshots in bug reports unreadable. Screenshots are graphics. They go to PNG or lossless-leaning WebP, and the day you need one to be small, shrink its dimensions rather than switching it to a photographic format.

If your source is animated — a GIF, an animated WebP — the current release now has genuine routes for it rather than a polite refusal. The image output menu has grown well past its first three entries: alongside JPG, PNG, and WebP, the raster outputs now include GIF, APNG, BMP, TIFF, TGA, and ICO, and GIF is an accepted input as well. GIF and APNG carry motion, so routing an animated source to one of them preserves the frames instead of flattening them, and the full set of active pairs is published at /conversions.

The philosophy I wrote about in Novus Convert launch: private file conversion with verified outputs still holds: the format directory is allowed to be bigger than the converter, and an upload control only appears where the release can produce a genuine, verifiable result. What has changed is how much of that directory is now live — the active matrix has expanded to hundreds of routes — so the honest answer to "can it do that format" is increasingly yes. Converter sites that list every extension ever invented and then upsell, fail, or silently mangle at runtime are still the specific product I did not want to build.

The practical guidance for animated sources today is simpler than it used to be: if you want to keep the motion, choose an animated output like GIF or APNG; if you only need a single frame or a poster image, choose a still format like PNG or JPG and know that you are deliberately dropping the animation. For heavy, long-running clips a dedicated video tool is still the better instrument — a thousand-frame capture is a video wearing the wrong costume — but short animations now convert directly. Every route arrives with the same validation gate as everything else, so a produced file has to prove out as a genuine, decodable result before the download unlocks.

SVG occupies a special seat among the accepted inputs because it is not pixels at all — it is geometry, instructions for drawing that stay perfectly sharp at any size. Rasterizing an SVG to JPG, PNG, or WebP trades that infinite scalability for universal compatibility, and the trade is one-way: no converter on earth can turn the resulting pixels back into clean geometry. So the first rule of this route is boring and absolute — the .svg source file stays archived forever, and the raster output is treated as a disposable rendition for one destination.

The output pick follows the same logic as the graphics section, because a rasterized SVG is a graphic by construction. PNG is the default for its exact edges and preserved transparency, which matters for the logos and icons that dominate real SVG collections. WebP serves the web-delivery case at a lower byte cost. JPG is the niche pick, defensible only when the SVG is a photographic illustration with no transparency and gradient-heavy fills — rare, but they exist. And because the output menu now reaches well beyond the big three — BMP, TIFF, TGA, and ICO are live raster targets too — an SVG icon can go straight to ICO for a favicon or to TGA for a game-art pipeline, with the full matrix of active pairs at /conversions.

When do I rasterize at all, given that browsers render SVG natively? At the boundaries where vector support ends: marketplace listings that accept only raster uploads, office documents headed to machines I do not manage, messaging apps that thumbnail unpredictably, and any print pipeline that asks for “a PNG at least this big.” Inside my own sites the SVG stays vector; the raster copy exists for the places that cannot cope, produced on demand and regenerated from source whenever needs change.

The JSON, CSV, TSV, and TXT routes look like the simplest converters in the app and hide the most judgment. The core mental model: a conversion between data formats preserves the intersection of what both formats can express, and silently sheds the rest. JSON expresses nesting, types, and objects inside objects; CSV expresses a flat rectangle of text cells. Flat, tabular JSON — an array of similar objects — crosses into CSV essentially intact. Deeply nested JSON does not, because there is no rectangle that means the same thing as a tree.

The round-trip consequences follow directly. JSON to CSV to JSON returns something close to the original only when the original was already rectangular, and even then the types come back changed: CSV stores text, so the number 42, the string "42", and a boolean all flatten into characters, and whatever parses the result must reconstruct types by convention. This is not a defect in any converter — it is the nature of the target — but it is exactly the surprise that corrupts a dataset three tools downstream if nobody thought about it at the picker.

Between the tabular formats, my rule is embarrassingly practical: TSV whenever the values themselves contain commas — addresses, prose fields, formatted numbers — because tab delimiters sidestep the quoting acrobatics that RFC 4180 exists to standardize, and spreadsheet imports go smoother. CSV when a system explicitly demands it, which many do. The parser underneath treats inputs as data rather than trusting extensions, so a malformed file fails the conversion cleanly instead of shipping garbage forward, and the original is never modified either way.

The TXT route rounds out the set for the times the destination is a human or a log pipeline rather than a parser. And all the structured routes share the same honest ceiling documented at Novus Convert — inputs up to 25 MB, processed entirely in browser memory — which comfortably covers exports, configuration files, and working datasets while staying out of the big-data business it was never meant for.

The archive routes — ZIP, TAR, TAR.GZ — sound interchangeable and serve different social worlds. ZIP is the archive format ordinary computing understands natively: double-click on any desktop OS and it opens, no explanation required. It compresses each entry independently, which allows pulling one file out without unpacking the rest. When an archive is headed to a client, a colleague, or anyone whose tooling I cannot predict, it becomes a ZIP, and I never have to write instructions.

TAR.GZ earns its place through lineage and ratio. It compresses the entire stream as one body rather than entry by entry, which typically packs tighter — noticeably so across many small similar files, like source trees or log collections. It is also the native dialect of the Unix world, where build systems, deployment pipelines, and package tooling expect it. Repackaging a downloaded ZIP as TAR.GZ for a Linux-side workflow, or the reverse for a Windows-bound handoff, is precisely the unglamorous job these routes exist for. Bare TAR, uncompressed, is the narrow case: a container for tooling that will handle compression itself.

Because archives are containers for arbitrary content, this is the corner of the app with the strictest guardrails, and choosing an archive output implicitly accepts them. Inputs are treated as untrusted: entries attempting path traversal are rejected, entry counts and expansion are capped — 200 MB compressed in, at most 5,000 entries, at most 512 MB unpacked — TAR checksums are verified, and the produced container is validated before download like every other route. An archive that fails those checks fails loudly, which beats a browser tab quietly drowning in a decompression bomb.

Sometimes the format is already right and the file is simply too heavy, which is why compression lives at its own surface, /compress, instead of being tangled into format conversion. It accepts JPG, PNG, and WebP, exposes an actual quality control, re-encodes locally, and — the part I insisted on — reports the measured output size before you download. Not an estimate, not a marketing “up to 80% smaller,” but the real byte count of the file you are about to receive, so the trade-off is made with open eyes.

My working method with the dial is to find the cliff. Visual quality degrades non-linearly: a photograph typically survives a substantial quality reduction with no visible change, then crosses a threshold where blockiness and smearing arrive all at once. I step downward, watching the size fall, and stop one step above where degradation becomes noticeable at the destination’s viewing size — a thumbnail tolerates far more compression than a hero image. The measured size readout turns this from guesswork into a two-minute calibration.

The dial also has a boundary worth respecting: compression solves byte problems, not pixel problems. If an image is oversized because it is 6000 pixels wide and will display at 800, quality reduction is attacking the wrong variable. I wrote up the full reasoning in How to compress an image without losing quality, but the short version fits in a sentence — get the dimensions right for the destination first, then spend the quality budget on whatever weight remains.

Every route in Novus Convert ends at the same checkpoint: before a download is enabled, the result must prove it is what it claims to be. Image outputs must carry the right signature and actually decode. Archives must present a valid container with intact structure. Data outputs must parse as the format they wear. A result that fails any of these checks is reported as a failure — even though processing technically produced bytes — because bytes with a confident extension and broken insides are the worst artifact a converter can emit.

The failure modes this catches are the plausible everyday ones, not exotic corruption: an encrypted archive that cannot legitimately be repackaged, an image variant whose codec the browser cannot fully decode, a JSON export truncated by whatever produced it, a file whose extension lied about its contents from the start. Renaming-as-converting is the oldest scam in the file-tool business, and the signature check at intake plus the validation gate at exit are the two locks against ever committing it, in either direction.

For you, the picker workflow ends with a habit worth keeping even with the gate in place: after choosing outputs deliberately, open one result from each category before shipping the batch onward — one image, the head of one CSV, one archive listing. The walkthrough at How to convert and compress files privately with Novus Convert bakes this spot-check into the first run. Validation guarantees the file is structurally the format you chose; thirty seconds of looking confirms it is also the content you meant.