Troubleshoot failed conversions in Novus Convert

When a row fails, stop and note which stage rejected it. A file refused as you add it means the signature check could not match the content to a supported input. A failure during processing means decoding or parsing broke partway. A row that finished processing but never unlocked its download failed output validation — the result did not prove out as a well-formed file of the promised type, so the gate held it back.

Each stage points somewhere different: rejection at intake points at the file's identity, mid-processing failure points at the file's content or its size, and a validation failure points at a result not worth having. Retry the row once — transient memory pressure does clear — but if the same failure repeats, believe it and move to diagnosis rather than clicking retry a third time.

The single most common culprit is a file that is not what its name claims. Files get renamed in transit constantly: a WebP saved from a website as .jpg, an HTML error page downloaded as .csv, an export truncated mid-write that kept its confident filename. Because Novus Convert identifies files by signature, these impostors surface immediately — where a filename-trusting tool would fail later and more confusingly.

The reliable fix is to go back to whatever application genuinely owns the data and re-export a fresh copy: the camera roll for photos, the spreadsheet or database for data, the original archiver for archives. If you want to see the problem for yourself first, open a suspect data file in a plain text editor — a "CSV" that begins with a < is a web page wearing a costume.

Some failures are boundaries rather than bugs. Encrypted and password-protected archives cannot be read without their key and always fail — decrypt them in the tool that made them, then convert. The occasional HEIC or HEIF from unusual hardware carries a codec variant the local decoder cannot handle, and re-exporting the photo as JPG from the device itself is faster than fighting it.

The other boundary is the format directory: pages exist for MP4, DOCX, EPUB, CAD, and other common formats as reference guides, without an active converter behind them. If the page you are on has no upload workflow, no amount of retrying will convert that format in this release — the honest move is the directory's, telling you up front instead of failing at the end.

The active set has grown, though, so do not assume a format is reference-only just because it is uncommon. The image routes now accept BMP and TIFF/TIF on top of HEIC, HEIF, AVIF, JPG, PNG, WebP, and SVG, and produce GIF, APNG, BMP, TIFF, TGA, and ICO as well as JPG, PNG, and WebP. Before writing off a pair as unsupported, confirm it against the full matrix at /conversions — the upload control on the pair's page is the reliable signal that the route is live.

Every route has a ceiling, and a file just over one fails reliably no matter how many times it is retried. Images: 100 MB and 80 megapixels. Structured text: 25 MB. Archives: 200 MB compressed, 5,000 entries, 512 MB expanded. These exist because the entire pipeline lives in your tab's memory, and the archive caps double as archive-bomb protection.

Getting under a limit is usually a source-side edit. A panorama over the megapixel cap can be scaled down before converting; a giant export can be filtered to the rows and columns that matter; an oversized archive can be split into several smaller ones and run as separate rows. If a workflow genuinely needs more than a limit allows, a desktop tool is the right instrument for that one job — the browser caps are safety, not stubbornness.

Sometimes every individual file is fine and the run is the problem: dozens of large rows queued at once, conversions slowing to a crawl, or late rows failing after early ones succeeded. That pattern is browser memory pressure, not file damage. The same tab is holding sources, working buffers, and finished results simultaneously, and it eventually runs out of room.

The remedy is rhythm. Process a large job in waves of a handful of files: run a wave, download its results, remove those rows to release their memory, then queue the next wave. Keep the tab foregrounded while work is running, and close memory-hungry neighbors — background tabs get throttled, and a starved tab fails jobs that would succeed in a quiet one. Splitting costs a few minutes and rescues batches that look hopeless.

Two non-failures masquerade as failures. First, daily download allowances: downloads are counted per input format per local calendar day — currently 15 for HEIC or HEIF, 20 for AVIF, 10 for archives, 50 for structured text, and 25 for other active formats — and the remaining count is displayed beside the download action. An exhausted allowance blocks the download, not the conversion, and it resets with the local day.

Second, expired results: finished files live at temporary URLs that vanish when their row is removed or the page closes. A download that no longer responds after you cleaned up the queue or restored an old tab is not a conversion failure — the result is simply gone, and re-running the row recreates it in moments since the source never left your machine.

If a file passes every check above — correctly identified, supported route, under the limits, failing alone in a fresh quiet session — you may have found a real bug, and a good report gets it fixed. Send it through the contact page at Contact with the details that make it reproducible: the input format and target output, the file's size and rough dimensions or row count, the browser and operating system, where in the flow it failed, and the exact wording shown on the row.

Note what you already tried — the retry, the fresh session, the smaller batch — so the fix starts where your testing ended. And since conversions run locally, your file never left your machine and no server log saw the failure; describing the file is genuinely useful precisely because nobody else can. If you can reproduce the same failure with a non-sensitive stand-in file, mention that too — it is the fastest path to a fix.