Convert JPG to PNG Online (Photo to Lossless PNG)
Decode a JPEG once and write PNG pixels with intentional color, alpha, chunk, and file-size choices.
- Add a file Choose or drop it here
- Pick the format Change it whenever needed
- Download the result After conversion completes
PNG Stores the Decoded JPEG Image, Not Its Original Compression
JPG and PNG are both raster formats, but their conversion boundary matters. JPEG usually codes component blocks with lossy quantization and often reduced chroma resolution. PNG filters rows and compresses them losslessly in IDAT data. To make PNG from JPG, a converter decodes the JPEG pixels, applies any intentional orientation and color conversion, then losslessly compresses those decoded samples. The PNG does not recover texture erased by JPEG quantization, and it does not keep the original JPEG scans merely because the visible image is similar.
This can be a useful last lossless step: once the JPEG has been decoded, later PNG saves can preserve those exact resulting samples if they are not edited or converted. It is not a quality upgrade. Block boundaries, ringing near sharp edges, and low-resolution chroma from the source can remain visible. For photographs, PNG may be much larger than JPG because photographic pixels are less compressible by PNG's lossless method. Keep the original JPG when compact source storage, camera metadata, or its existing profile markers matter.
PNG Chunks Define Pixels, Transparency, and End of File
A PNG begins with an eight-byte signature and uses typed chunks. IHDR supplies width, height, bit depth, color type, compression method, filter method, and interlace method. One or more IDAT chunks carry the compressed filtered image data, and IEND ends the stream. A valid writer must make these agree: if IHDR describes 8-bit RGB, the decoded rows must contain that model; if it describes RGBA, four samples are required. Adding a .png filename to a JPEG does not create chunks or valid filtered data.
PNG can express a full alpha channel in grayscale-alpha or RGBA color types, while the tRNS chunk offers transparency for palette entries or a single transparent sample in certain color types. An ordinary JPG has no alpha channel. A JPG-to-PNG tool can produce a fully opaque RGB PNG, or it can create transparency only when a separate operation deliberately selects pixels, removes a background, or composites an alpha mask. Inventing an alpha channel from JPEG compression noise creates fringing rather than genuine transparency. Alpha values are linear fractions of full opacity, and PNG gamma correction is not applied to alpha.
What JPG to PNG Preserves, Stops Losing, and Cannot Repair
- Preserves decoded samples losslessly: further PNG saves need not add JPEG-style coding loss.
- Keeps source dimensions: no new pixels are created by changing containers.
- Can carry explicit color chunks: iCCP, sRGB, or gAMA/cHRM can state intended color behavior.
- Can gain designed alpha: only after a real masking or background-removal step.
- Cannot restore JPEG detail: lossy artifacts and chroma limits survive the decode.
- May lose source metadata: EXIF and JPEG application markers are not automatically a PNG equivalent.
Choose PNG for web graphics, screenshots, UI assets, or an image that will be edited repeatedly after the one JPEG decode. For an untouched photographic delivery, JPG may remain smaller and sufficient. For a transparent graphic, make the transparency decision explicitly and inspect edge pixels over both light and dark backgrounds before replacing any source file.
Color Chunks Prevent Ambiguous PNG Rendering
Color appearance is not determined by RGB byte values alone. PNG has several color-signaling mechanisms. The current W3C specification gives precedence to cICP, then iCCP, then sRGB, then cHRM and gAMA. If iCCP is present, its embedded ICC profile defines the image color space; color-image profiles must be RGB. The specification recommends that an encoder writing iCCP also write approximate gAMA and cHRM for decoders that do not understand the profile. An sRGB chunk identifies standard RGB and includes a one-byte rendering intent.
Do not write contradictory color labels. Unless cICP exists, a PNG should contain at most one embedded profile, explicit iCCP or implicit sRGB. A converter should either retain an appropriate RGB ICC profile, convert samples to sRGB and mark them accordingly, or leave color unknown when that is truly all it knows. The gAMA chunk must occur before IDAT and before PLTE if a palette exists. A color shift after conversion often comes from dropped or conflicting color information, not from IDAT compression. Test in the actual browser, editor, or delivery system that will render the PNG.
Large Files, Halos, and Rotated Pictures Point to Different Fixes
A PNG larger than its JPG source is often expected, especially for a photographic scene. PNG compression is lossless and cannot exploit JPEG's irreversible perceptual reduction. Reduce dimensions only when the target display does not need the original pixels; do not repeatedly reconvert in search of nonexistent quality. If web delivery size matters, compare a carefully chosen JPG, PNG, and another supported modern format at the required dimensions, while retaining the source. Changing PNG compression settings changes file size and encoding effort, not the decoded image quality.
A halo around a newly transparent object indicates an imperfect background-removal mask or colors that were blended against the old matte. Repair the alpha/matte treatment in an editor, not by toggling a PNG chunk. A sideways PNG usually means EXIF orientation was honored by the JPEG viewer but not baked into pixels; normalize orientation before writing IHDR dimensions and rows. If colors look too dark or light, inspect sRGB, iCCP, and gAMA choices. If a reader rejects the file, validate the signature, IHDR, IDAT sequence, CRCs, and IEND with a PNG-aware tool rather than renaming the extension.
JPEG Source Details Compared With an RGB or RGBA PNG
| Detail | JPG | PNG |
|---|---|---|
| Image coding | Lossy component/block coding | Lossless filtered rows in IDAT |
| Transparency | Normal JPG has none | RGBA alpha or tRNS where applicable |
| Start data | JPEG markers | Signature then IHDR |
| Color declaration | Possible APP2 ICC profile | cICP, iCCP, sRGB, or gAMA/cHRM |
| Orientation | May have EXIF instruction | Pixels should be physically normalized |
| File-size tendency | Often compact for photos | Often larger for photographic pixels |
JPG to PNG Questions for Correct Pixels and Transparency
Does PNG improve a JPEG photo?
No. It can preserve the decoded result without another lossy JPEG save, but it cannot rebuild discarded detail.
Why is the PNG bigger?
Lossless PNG compression is commonly less compact for photo noise and texture than JPEG's lossy coding.
Will JPG transparency appear in PNG?
JPG has no normal alpha. A PNG needs a separately created mask or transparent-background operation to gain meaningful alpha.
Why are colors different?
Check whether the source profile was retained, converted to sRGB, dropped, or contradicted by PNG color chunks.
Why did the converted PNG rotate?
Apply EXIF orientation to the raster before encoding; PNG viewers should not be expected to infer the JPEG instruction.
A reliable export record notes the decoded width and height after orientation, RGB or RGBA color type, bit depth, alpha source if any, color-chunk policy, and whether the original JPG's ICC profile was retained or converted. This turns vague visual reports into testable questions. For example, a dark display can be checked against the written sRGB or iCCP choice, while a transparent fringe can be traced to the matte pixels rather than blamed on generic PNG compression.
Validate at native dimensions and over contrasting backgrounds. Inspect the PNG in a chunk-aware tool, then in the actual browser or application that will receive it. Ensure IHDR matches the intended color type, all IDAT data is present, IEND closes the stream, and only one non-cICP profile route is asserted. Keep the JPG source for provenance and the PNG as the lossless editing or delivery derivative.
For a simple opaque photograph, an RGB PNG with a deliberate color label is usually clearer than unnecessary alpha or palette conversion. For a cutout, inspect pixels along hair, text, and soft shadows before handoff; those are the places where a poor mask becomes visible.
PNG filtering happens before lossless compression and helps make neighboring row values compress efficiently; it does not blur, sharpen, or otherwise alter the decoded pixels. That is why two encoders can make different-sized PNG files that render identically. For auditability, keep a checksum or native-pixel comparison of the decoded source and the resulting PNG after the one intended color/orientation operation. This distinguishes a harmless compression-setting difference from an accidental resize, color conversion, or second lossy JPEG decode.
Palette PNG can be compact for a logo with few colors, but converting a continuous-tone photograph to a limited palette is a separate quantization decision that can band gradients. Use full RGB or RGBA for a photographic conversion unless the destination explicitly needs indexed PNG. If a palette is used, inspect its PLTE and any tRNS entries, and compare the output at 100 percent for posterization.