Image Troubleshooting
Last reviewed:
Start with the symptom, preserve the original, and change one variable at a time. Repeatedly renaming or converting a file can hide the cause and create additional loss.
Quick diagnostic map
| Symptom | Likely category | First useful check |
|---|---|---|
| File will not open | Wrong type, unsupported format, damage | Verify the real format and file size |
| Upload rejected | Type validation, limit, corruption | Check selected source, extension, MIME, and limits |
| Conversion fails | Unsupported route, decode/encode failure, resource limit | Test one valid representative file |
| Output is larger | Destination compression or dimensions | Compare compression model and pixel dimensions |
| Output looks blurry | Lossy encoding, scaling, weak source | Compare at 100% and final size |
| Background turns black/white | Transparency flattening or viewer behavior | Confirm source alpha and destination support |
| Colors change | Color profile or application interpretation | Compare in color-managed software |
| Animation disappears | Single-frame output or unsupported animation | Check current frame policy |
Step 1: Protect the evidence
- Do not overwrite the source.
- Make a working copy if you need to rename, inspect, or test it.
- Record the original filename, extension, file size, and where it came from.
- If a download or transfer was interrupted, obtain a fresh copy before conversion.
Step 2: Verify the real format
An extension is a hint, not proof. A file named image.png may still contain JPEG or unrelated data. Renaming does not convert it. Use a trusted application or file-signature inspection, and compare the result with File Extension vs File Format.
If the real type is unsupported by the receiving application, converting from that verified source to a compatible output may solve the problem.
Step 3: Separate unsupported from damaged
An unsupported file can be perfectly valid but unreadable to one application. A damaged file contains missing or inconsistent data. Try a current trusted viewer known to support the format. If several independent tools cannot decode it, obtain another copy or return to the source application.
Do not upload sensitive files to a succession of unknown repair sites. Consider privacy and whether local processing is more appropriate.
Decode errors versus encode errors
A decode error occurs while reading the source. Causes include truncated data, malformed structure, unsupported variants, extreme dimensions, or a source-type mismatch. An encode error occurs after decoding, while writing the destination. Causes can include an unsupported feature, output-size limit, resource limit, or encoder failure.
This distinction matters because changing the destination cannot fix a source that cannot be decoded. Conversely, a source can open correctly while one particular output route fails.
Pixel limits and decompression risk
Compressed byte size does not reveal decoded memory demand. A small file can declare enormous dimensions or expand into many pixels. Responsible processors enforce byte, pixel, frame, time, and output limits to protect service availability.
If a file exceeds a pixel limit, use a trusted local editor to create a correctly sized derivative when policy allows. Do not evade safety checks by changing the extension or repeatedly uploading altered copies.
Diagnose by controlled substitution
- Keep the failing source unchanged.
- Try one known-good file of the same real format.
- Use the same source with a different supported destination.
- Use a different source with the original destination.
- Compare which stage changes the result.
If every source fails for one destination, investigate the route or encoder. If one source fails across destinations, investigate that source. If a file works locally but not in the service, compare limits and supported variants.
Safety warning signs
- The file came from an untrusted sender and asks you to disable security controls.
- The extension, media type, and detected content disagree.
- The file declares implausible dimensions or frame counts.
- A repair site requests unnecessary personal data or permanent account access.
- The only copy is being overwritten during each attempt.
Preserve evidence, use trusted tools, and follow organizational security policy for suspicious uploads.
Step 4: Check route and limits
ForgeConvert supports specific source-to-destination routes. Current limits include up to 20 files per batch, 8 MB per source file, 40 megapixels per decoded image, and a processing time limit. A file can be within the byte limit but exceed the pixel limit after decoding.
Test one file that clearly matches the selected source. If it passes, compare the failed file’s type, dimensions, complexity, and integrity.
Step 5: Diagnose the output
File is larger
Lossless PNG or TIFF output can be larger than a lossy JPEG source. See Image Compression Explained.
Image is blurry or blocky
The source may already lack detail, or lossy encoding and display scaling may add defects. See Image Quality Guide.
Transparency is gone
JPEG cannot store alpha. Conversion to PNG does not create transparency in an opaque source. See Image Transparency Guide.
Image is rotated
Camera orientation may be stored as metadata rather than baked into pixel order. Applications and conversion paths can interpret or remove that metadata differently.
Animation is gone
A format’s ability to animate does not prove the converter outputs multiple frames. ForgeConvert currently produces single-frame output.
Corrective conversion paths
Conversion is useful when the file is valid but the destination cannot use its format. Common examples include HEIC to JPG for broad photo compatibility, WebP to PNG for applications that reject WebP, and SVG to PNG for a fixed-size raster derivative.
Do not convert merely because a file is damaged. A decoder must first read enough valid source data.
When to stop troubleshooting
Stop and seek a fresh source when the file is truncated, every trusted decoder rejects it, or repeated recovery attempts risk overwriting the only copy. Stop converting when the destination cannot represent a required feature. Keep the original when an output passes compatibility but loses editing structure, metadata, animation, or transparency you may need later.
Frequently asked questions
Can I repair an image by changing its extension?
No. A new extension does not repair or re-encode data.
Why does a website say my image type is wrong?
The site may inspect the actual file signature rather than trusting the extension, or it may accept fewer formats than your device can display.
Can a converter open a file my computer cannot?
Possibly, if the file is valid and the converter supports its format. That is a compatibility difference, not proof the file was repaired.
What should I check before converting again?
Real type, source integrity, route support, limits, dimensions, required features, and the destination application.