What the measured run showed
These figures describe the controlled fixture documented for this guide. They are evidence for the tested case, not a universal performance guarantee.
The HEIC fixture and what we measured
The source was a synthetic 640 × 360 HEIC image with visible test graphics and several EXIF fields: camera make, model, capture date, artist, and an orientation tag. The final encoded fixture was 4,681 bytes.
We passed that exact file through NetroDoc's HEIC to JPG, HEIC to PNG, and HEIC to PDF tools using the same Pillow/pillow-heif conversion paths used by the service, then reopened each output for structural checks.
- The source decoded successfully at 640 × 360.
- The observed EXIF Orientation value in the final fixture was 1.
- The fixture's encoder normalized our attempted Orientation 6 while creating the test file, so non-default orientation is not claimed as experimentally verified here.
HEIC to JPG: compatible, but not automatically smaller
The JPG output was 4,839 bytes, slightly larger than the 4,681-byte HEIC source in this fixture. That is a useful reminder that converting HEIC to JPG does not guarantee a smaller file.
Against the decoded HEIC image, the JPG measured 38.47 dB PSNR in our fixture. That indicates a visually close result in this controlled case, while still being a lossy re-encoding rather than a pixel-identical copy.
- Dimensions remained 640 × 360.
- The JPG was about 3.4% larger than the source HEIC in this specific test.
- Use JPG mainly for broad compatibility or workflows that expect JPEG, not because it must reduce bytes.
HEIC to PNG: exact decoded pixels in this fixture
The PNG output was 3,406 bytes. When we compared the decoded PNG pixels against the orientation-normalized decoded HEIC source, the pixels were identical in this test.
The PNG was also smaller than this particular HEIC fixture by about 27.2%. That is not a general promise: the source was synthetic and highly compressible. Photographs and camera HEIC files can behave very differently.
- Dimensions remained 640 × 360.
- Pixel comparison returned identical for this fixture.
- Do not generalize the measured size reduction to arbitrary HEIC photos.
EXIF metadata did not carry into JPG or PNG in the test
The HEIC fixture contained camera make, model, capture date, artist, and orientation information. After conversion, the JPG and PNG outputs did not expose those EXIF fields in our inspection.
That can be desirable for privacy when metadata contains device or capture details, but it can also remove information you intended to keep. If metadata matters to your workflow, verify the converted file rather than assuming the destination format preserved it.
- Camera make and model were present in the source fixture.
- The tested JPG output exposed no EXIF fields through Pillow.
- The tested PNG output exposed no EXIF fields through Pillow.
- This result describes the tested NetroDoc paths and fixture, not every metadata block that HEIC can contain.
HEIC to PDF creates a document page, not another image file
The PDF output was 7,641 bytes and contained one page. Its page size was 307.2 × 172.8 points for the 640 × 360 landscape fixture.
PDF is therefore a different kind of target: it is useful when the image needs to become a document page for sharing, printing, combining, or archiving in a PDF workflow. It should not be chosen merely as an image-compression format.
- The PDF validated as a one-page PDF.
- The landscape relationship was retained in this fixture.
- The PDF was larger than the source HEIC in this controlled test.
Multi-image HEIC is deliberately rejected
HEIC can be a container with more than one image. NetroDoc's current image validator is designed for a single image and rejects multi-image HEIC rather than silently selecting one frame or discarding the rest.
Our controlled multi-image fixture was rejected with the code image_multiframe_unsupported. That fail-closed behaviour is safer than producing a file that appears successful while omitting images the user expected to keep.
Choosing JPG, PNG, or PDF from HEIC
Choose the destination based on what you need after conversion. JPG is the practical compatibility target for many photo workflows. PNG is useful when you want a lossless decoded-pixel representation or a PNG-specific workflow. PDF is appropriate when the image needs to become a document page.
Compare the actual output size when storage matters. In our fixture, JPG became slightly larger, PNG became smaller, and PDF became larger than the source HEIC. Those numbers are evidence for this file, not a ranking that applies to every camera photo.
- JPG: broad image compatibility, with lossy re-encoding.
- PNG: pixel-identical to the decoded source in this fixture, but size depends strongly on content.
- PDF: a document container for the image rather than a direct image-format replacement.
Limits of this evidence
This was a synthetic HEIC fixture produced in the same runtime used for the NetroDoc test. It does not represent every iPhone, Android, camera, HDR, depth-map, Live Photo, or vendor-specific HEIC variant.
We specifically do not claim that EXIF Orientation values other than 1 were experimentally verified. The encoder normalized our attempted Orientation 6 while constructing the fixture, so that case remains outside the measured scope.
Temporary processing and privacy
The HEIC conversion paths use temporary request processing storage. In the tested application lifecycle, synchronous conversion work directories are removed after the response lifecycle completes, and known error paths remove the temporary work directory before returning an error.
Read the Privacy Policy →Troubleshooting
The JPG is larger than my HEIC
That can happen. Our fixture's JPG was slightly larger than the source HEIC. Convert for compatibility first, then compare actual bytes rather than assuming JPG is smaller.
My metadata disappeared
The EXIF fields in our fixture were absent from the converted JPG and PNG outputs. Keep the original HEIC if camera/capture metadata matters, and verify metadata in the destination file before relying on it.
A HEIC with multiple images is rejected
The current validator rejects multi-image HEIC with image_multiframe_unsupported instead of silently dropping frames.
Will a rotated HEIC always be corrected?
The implementation applies EXIF transpose, but our synthetic encoder normalized the non-default orientation before the evidence run. We therefore do not claim a measured Orientation≠1 result yet.
Method note
NetroDoc publishes measured claims only after a controlled run completes successfully. Untested cases are kept out of the conclusion. The evidence run for this publication wave used the same production runtime components while operating on an isolated candidate and temporary server paths.