Why Does My Converted Image Look Different? A Visual Troubleshooting Guide

A converted file rarely looks wrong in an obvious way. It's usually a small thing: a color that's slightly off, an edge that's a bit smudged, a background that's suddenly white instead of transparent. None of that means the conversion failed. Each symptom below has a specific, identifiable cause, and most of them take under a minute to confirm. Find what you're seeing, and work from there.

Colors smear or turn muddy around text and sharp edges

What you see: Fine lines, colored text, or thin shapes against a contrasting background look slightly blurred or discolored at the edges, even though the rest of the photo looks fine.

Likely cause: This is chroma subsampling, a step most JPEG encoders apply by default. JPEG stores brightness and color as separate channels, and because human eyes are far less sensitive to color detail than to brightness detail, most encoders store the color channels at reduced resolution to save space. That's invisible on a normal photograph, but on a sharp color boundary, like red text on a white background, the color information gets averaged across a small block of pixels, and the edge comes out fringed or muddy instead of crisp.

How to check: Zoom in tight on the exact edge that looks off. If the discoloration is concentrated right at a hard color boundary and fades a pixel or two into the surrounding area, that's the signature of chroma subsampling, not a general quality problem.

What to do: If the source image has flat colors, text, or line art rather than a photograph, PNG or WebP's lossless mode avoids this entirely, since neither one subsamples color the way JPEG does by default. If the destination has to be JPEG, look for an option, often labeled something like 4:4:4 or "no chroma subsampling," that disables it, at some cost to file size.

When not to convert: If the image is mostly text, a logo, or a screenshot with sharp color edges, don't route it through JPEG in the first place if you have another option, this symptom is close to unavoidable on that kind of content.

Colors look banded, or a smooth gradient turns into visible stripes

What you see: A sky, a shadow, or any smooth color gradient that looked continuous in the original now shows visible bands or steps, like a topographic map instead of a smooth blend.

Likely cause: Two different things cause this, and it's worth telling them apart. If you converted into a format with a limited color palette, GIF's 256-color limit is the classic case, the format is forced to round every pixel to its nearest available palette color, and a smooth gradient collapses into visible steps because there simply aren't enough distinct colors to represent it. The second cause is more aggressive JPEG compression: at low quality settings, the encoder discards enough fine detail that smooth gradients get flattened into broader, more uniform bands.

How to check: Look at the specific format you converted into. If it's GIF or an 8-bit/indexed PNG, palette limitation is almost certainly the cause. If it's a JPEG or WebP file at a low quality setting, it's compression, not palette.

What to do: For the palette case, converting to a truecolor format instead, PNG-24, JPEG, or WebP, removes the ceiling entirely. For the compression case, raising the quality setting on the export, or switching to a format with better gradient handling at the same file size, usually resolves it.

When not to convert: Avoid GIF or any indexed-color format for photographs or anything with smooth color gradients. It's built for flat, limited-color graphics, not continuous tone images, and gradients are exactly where that limitation shows.

The transparent background turned solid white

What you see: A logo, icon, or cutout image that had a see-through background now has a solid white (occasionally black) rectangle behind it.

Likely cause: The destination format has no alpha channel at all. JPEG, JFIF, and BMP fall into this category, none of them have any way to store "this pixel is see-through," so a converter receiving a transparent source has to pick a solid color to fill that area in, and it's gone the moment the file saves.

How to check: Look at the format you converted to. If it's JPEG or JFIF, this is expected behavior, not a bug, every conversion into those formats does this to every transparent pixel, without exception.

What to do: If transparency needs to survive, convert to PNG, WebP, or AVIF instead, all three support a full alpha channel. There's no setting on a JPEG export that preserves transparency, because the format itself has no slot for that data.

When not to convert: Don't convert a logo, icon, or cutout with a transparent background to JPEG or JFIF if it's going anywhere other than a background you fully control. The fill is permanent the instant the file saves.

The image looks softer or blurrier than the original

What you see: Fine detail, texture, or sharp focus that was present in the source looks slightly soft or smoothed over in the converted file, without any obvious color problem.

Likely cause: Usually one of two things. If you converted into a lossy format at a moderate or low quality setting, the compression's quantization step is discarding some of the fine, high-frequency detail that made the image look crisp, this is a normal, expected trade-off of lossy compression, not a malfunction. If the image was also resized during conversion, the resampling algorithm used to shrink or enlarge it can introduce its own softening, separate from any compression effects.

How to check: Compare the pixel dimensions of the source and the output. If they're identical and only the quality setting changed, it's compression softening. If the dimensions changed too, resizing is a contributing factor.

What to do: For compression softening, raise the quality setting, there's usually a point where the softness becomes acceptable well before you reach maximum quality. For resizing softness, some tools offer a sharpening pass after resampling, applied carefully, this can recover some of the perceived crispness without reintroducing the original file size.

When not to convert: If the image needs to stay pixel-perfect through multiple rounds of editing, work in a lossless format like PNG or TIFF until the final export, converting to a lossy format and back is where this kind of softening compounds.

The file got bigger, not smaller

What you see: The converted file is larger than the original, sometimes dramatically so, when the entire point of converting was usually to shrink it.

Likely cause: This happens whenever the destination format is less efficient at representing that particular image than the source format was, and it's more common than people expect. Across our own testing on this site, a 25.5 KB JPG converted to TIFF came back at 479.49 KB, an increase of over 1,700%, because TIFF's lossless storage has to record far more raw data per pixel than JPEG's compressed format does. A WebP file converted to PNG showed the same pattern for the same underlying reason. Neither result is a bug, it's the direct cost of asking a compact format to become an uncompressed or less-efficient one.

How to check: Look at what format you converted from and into. If you went from a compressed, lossy format toward an uncompressed or lossless one, TIFF, BMP, or PNG from a JPEG or WebP source, a size increase is expected, not unusual.

What to do: If the goal was a smaller file, check that the destination format is actually more efficient than the source for this kind of image, not just "different." If you specifically need the lossless properties of the bigger format, for archiving or further editing, the size increase is the trade-off you're paying for, and it's working as intended.

When not to convert: Don't convert a compressed web format to an uncompressed archival format expecting a smaller result, that direction almost never shrinks a file, regardless of the specific formats involved.

The animation stopped moving

What you see: An animated GIF, converted to another format, opens as a single still frame instead of playing.

Likely cause: Most common image formats, JPEG, standard PNG, and BMP among them, have no concept of multiple frames or timing at all, they're built to hold exactly one static image. When a converter receives an animated source and has to produce one of these formats, it can only keep one frame, almost always the first, and discard the rest of the sequence along with the motion.

How to check: Look at what format the animation was converted into. If it's JPEG, standard PNG, or BMP, losing the animation is expected every time, not a conversion failure, regardless of the specific file or its size.

What to do: If the motion needs to survive, the destination has to be a format that actually supports multiple frames: animated WebP, animated PNG (APNG), or AVIF's image sequence mode all preserve animation. Converting an animated GIF to any of those keeps the motion; converting it to JPEG, standard PNG, or BMP never will, regardless of settings.

When not to convert: Don't convert an animated file to JPEG, standard PNG, or BMP if the animation itself is the point, pick an animation-capable destination format instead, or keep the original GIF.

The file won't open, or shows a blank or broken icon

What you see: A converted (or occasionally an unconverted) file refuses to open in a browser, an app, or a piece of software, sometimes with an error, sometimes just a generic broken-image icon.

Likely cause: The destination software or platform doesn't support that particular file format at all, this is especially common with formats built for other purposes, TIFF is a good example. TIFF is standard in print and archival workflows but isn't natively supported by mainstream web browsers, so a TIFF file dropped into a browser, or embedded in a webpage, typically won't render.

How to check: Try opening the same file in a different, more mainstream piece of software, an image viewer, a different browser. If it opens fine elsewhere, the issue is that specific destination's format support, not a corrupted file.

What to do: Convert to a format the destination actually supports. For anything headed to a browser or general-purpose software, JPEG, PNG, or WebP are safe, close to universal choices.

When not to convert: If a file is meant to move between very different environments, a print shop, a web page, an email, don't assume one format serves every destination. Match the format to where the file is actually going.

A quick way to confirm any of this yourself

Most of these symptoms are easier to diagnose with the original and the converted file open side by side than from memory. Running the same source file through our converter and comparing the properties panel, the visible result, and the file size against the original is usually enough to tell you which of the causes above you're actually looking at.