- Nationwide Digital Forensic & Cyber Investigation Services
Image formats organize compressed samples, descriptive records, previews, and display instructions differently. A structural examination follows declared boundaries instead of treating every visible byte pattern as a real object.
Home › Digital Evidence Authentication › Photo and Image Authentication › Image File Structure: JPEG, PNG and HEIC Explained
Quick Answer. Image file structure is the organization of encoded pixels, metadata, and references inside a picture file. JPEG uses markers and segments, PNG uses typed chunks with checksums, and HEIC commonly uses boxes and referenced image items. Examiners validate lengths, ordering, and references before interpreting metadata or deciding whether unexplained bytes represent damage, software behavior, or concealed content.
This structural chapter of Photo and Image Authentication explains what a parser must follow to reconstruct an image and its supporting records. Start with format signatures when the extension is uncertain, then use EXIF analysis to interpret descriptive fields within the mapped container. Structure tells us where a record lives and whether it can be read reliably. It does not make the record a trustworthy statement about capture.
| Question | Short answer |
|---|---|
| How is JPEG file structure organized? | SOI begins the stream, marker segments describe tables and frames, SOS introduces scan data, and EOI closes the codestream. Progressive images contain multiple scans. |
| How is PNG file structure organized? | An eight byte signature precedes chunks. IHDR describes the image, IDAT carries compressed image data, and IEND closes the PNG datastream. |
| How is HEIC file structure organized? | ISO base media boxes describe brands, image items, properties, and data locations. The primary displayed image can be a derived item built from other items. |
| Why do image structure parsers disagree? | Readers vary in error recovery, supported features, and tolerance for extra data. An examiner resolves the disagreement against byte boundaries and format requirements. |
| Does image file structure reveal a crop? | Sometimes. A source preview, edit metadata, or HEIC display property can preserve relevant information. A flattened export may contain only the cropped pixels. |
| Can image structure contain more than one picture? | Yes. Previews, auxiliary images, multiple frames, or separate items can coexist. Their declared roles matter more than simply counting embedded signatures. |
A JPEG frame entry defining a component identifier, sampling factors, and quantization table selector.
A check value calculated over chunk type and data, excluding the chunk length.
A location and length description used to locate the bytes belonging to a HEIF item.
The HEIF metadata entry that identifies the primary image item.
The mapping between HEIF items and properties stored in the item property container.
The HEIF box holding descriptive entries that identify item types and related information.
A JPEG codestream starts with SOI, FF D8. Most following marker segments contain a two byte length in big endian order. That length includes the two length bytes but excludes the marker itself. A parser uses it to skip the segment payload safely rather than searching for the next apparent marker within arbitrary binary content.
| JPEG object | Marker | Structural role |
|---|---|---|
| APP0 | FF E0 | Often carries a JFIF identifier and density information |
| APP1 | FF E1 | Can carry Exif TIFF data or an XMP packet |
| DQT | FF DB | Defines quantization tables selected by frame components |
| SOF0 or SOF2 | FF C0 or FF C2 | Defines baseline or progressive frame parameters |
| SOS | FF DA | Defines scan component selection before coded scan bytes |
Within entropy coded scan data, a literal FF byte is represented using FF 00 stuffing. Restart markers, when used, divide decoding intervals. A simple search for FF followed by any value will therefore misidentify boundaries. The decoder must account for stuffing, restart markers, and the coding process. Progressive JPEG also returns to markers for later scans rather than placing every coefficient in a single scan.
SOI, EOI, and restart markers do not have ordinary segment length fields. Applying the general length rule to them shifts every subsequent offset and creates false anomalies. A useful segment inventory records each marker offset, declared length where applicable, payload identifier, and the next expected boundary. Compare that inventory with a complete decode rather than trusting a preview generated by the operating system.
The first valid EOI, FF D9, closes that codestream. Additional bytes may be padding, a second resource, or unrelated material. Record their exact range and content. A second JPEG inside an APP1 thumbnail is not equivalent to a second JPEG appended after the main image. The compression examination uses this structural map to associate tables and scans correctly.
We inspect declared boundaries, unused material, and image relationships to explain what a normal viewer displays and what it ignores.
Request Confidential Consultation Call (833) 292 3733PNG begins with 89 50 4E 47 0D 0A 1A 0A. Each chunk then contains a four byte data length, a four byte type, that many data bytes, and a four byte CRC. Numeric lengths use network byte order. The CRC covers the type and data, not the length or its own stored value. A correct CRC indicates agreement of those bytes with a check value, not authenticated authorship.
| PNG chunk | Expected content | Examination question |
|---|---|---|
| IHDR | Width, height, bit depth, color type, and coding methods | Do the dimensions and pixel representation match the decoded output? |
| PLTE | Palette entries where applicable | Is the palette required and correctly ordered for this color type? |
| IDAT | Consecutive portions of one compressed image stream | Does the combined stream decompress to valid scanlines? |
| eXIf | Exif metadata represented as TIFF structure | Are offsets valid within the metadata data area? |
| IEND | Zero data bytes | What remains after the closing chunk, if anything? |
Multiple IDAT chunks do not mean multiple pictures or editing sessions. Encoders may divide the same compressed stream into different chunk sizes without changing the reconstructed pixels. The image stream includes filtering choices for scanlines before compression. Different filters and compression settings can produce different file bytes for identical samples.
Text can appear in tEXt, compressed text in zTXt, and international text in iTXt. Preserve the keyword, encoding details, and raw payload before extracting text. Color information can appear in chunks such as iCCP, sRGB, or gAMA, subject to specification rules. Different viewers may render the same sample values differently when they honor different color information. That is not automatically evidence of pixel replacement.
Unknown ancillary chunks can be legitimate extensions. Interpret chunk type properties and current format specifications rather than deleting unfamiliar material. A repaired PNG should be a separate derivative with a new digest and an operation log. Otherwise an attempt to make the file readable can erase the very defect the examination needs to explain.
HEIC commonly uses the ISO base media organization. An ordinary box starts with a four byte size and four byte type. Special size values alter how the boundary is interpreted, so a robust parser checks those rules before stepping to the next box. The ftyp box declares a major brand and compatible brands. Brands such as heic and mif1 describe format compatibility, not the make of a particular phone.
The meta box organizes item information and relationships. Its children can include iinf for item descriptions, iloc for locations, pitm for the primary image, and iprp for item properties and their associations. The primary item can be a grid derived from several coded tile items. Taking the first HEVC payload encountered may produce only one tile rather than the complete displayed photograph.
Item properties can describe spatial extents, codec configuration, rotation, mirroring, or cropping. Auxiliary resources can hold depth or other supporting image information. An Exif item is metadata, not necessarily a picture. A complete report should identify item IDs, item types, references, properties, and the data extents used for the primary rendering. Keep identifiers exactly as parsed so another examiner can trace the same reconstruction.
A conversion to JPEG may flatten the displayed primary image and discard depth resources, item relationships, or capture metadata. That conversion is a new representation, not a faithful structural duplicate. If the dispute concerns portrait processing or native phone resources, request the HEIC file and associated library records rather than analyzing the JPEG export alone.
A structural anomaly establishes a discrepancy that needs explanation. An APP1 length that extends beyond the file can indicate truncation, an invalid write, or deliberate construction. An out of bounds HEIC extent can make an item unrecoverable. A PNG CRC mismatch can result from changed data or corruption of the stored checksum. None of these observations identifies the responsible person.
Record whether a strict validator rejects the file, whether a tolerant decoder opens it, and what each decoder displays. If one reader ignores a malformed tail while another stops early, preserve both results. A screenshot of the successful display is not a substitute for documenting the malformed object. The goal is to explain how readers handled particular bytes.
Distinguish a nonconforming layout from a prohibited layout only after consulting the correct format version and extensions. Newer PNG features and HEIF resource relationships can surprise older software. Conversely, a familiar viewer may quietly repair a damaged stream and conceal missing rows or substituted pixels. Independent parsing and a full resolution decode make that behavior visible.
The conclusion should identify exact offsets, lengths, affected resources, and the consequence for interpretation. For example, an invalid thumbnail offset can undermine the extracted preview without invalidating the main JPEG scan. This resource specific explanation is more useful than labeling the entire image suspicious.
Work from a verified copy and maintain an offset inventory that another examiner can reproduce.
We map image resources, diagnose parser disagreements, and explain whether an anomaly affects the primary picture, a preview, metadata, or unused material. The analysts doing this work are subject matter experts in image file structure who read JPEG markers, PNG chunks, and HEIC boxes directly.
Elite Digital Forensics is an independent digital forensics practice serving attorneys, paralegals, in house counsel, insurers, lenders, businesses, and individuals nationwide. Our team includes former law enforcement forensic examiners and court qualified expert witnesses in computer, cell phone, cloud, document, and multimedia forensics. Every engagement begins with a scoped plan, hash verified evidence handling, and a clear explanation of what the examination can answer.
Yes. Exif and XMP can occupy separate APP1 segments, and additional arrangements are possible. Identify each payload and its boundaries rather than assuming one APP1 record.
Not generally. Chunk order supports decoding and metadata placement, not a complete chronological edit log. Export software can rebuild the entire file.
A thumbnail supports quick browsing without decoding the primary resource. Its presence and role should be identified through item metadata and relationships.
It can describe the damage and compare likely mechanisms, especially with reference copies. An isolated invalid length often cannot establish whether the cause was accidental or intentional.
No. Preserve the received file unchanged. Any repaired version should be a separately hashed derivative with every modification documented.
Raw byte inspection is useful for verifying offsets and disputed boundaries, but structured parsing and actual decoding are also needed. A hex display alone does not reconstruct every format rule.
A defensible structural account names the container, follows its references, and explains what the viewer reconstructed. That map gives later metadata and compression findings a reliable technical foundation. Our court qualified experts in image forensics can explain how the internal structure supports or contradicts the claimed source of a photo.
Request Confidential Consultation Call (833) 292 3733This content is for educational and informational purposes only and does not constitute legal advice. Elite Digital Forensics provides independent digital forensic services and expert witness testimony; we do not provide legal representation. Every case is fact specific; outcomes depend on the evidence, jurisdiction, and counsel. Retain qualified legal counsel for advice about your matter.
Elite Digital Forensics Assistant
By submitting this form, you consent to be contacted by email, text, or phone. Your information is kept secure and confidential. Reply Stop to opt out at anytime.
IMPORTANT: Please remember to check your spam or junk folder