Raw Byte Identification of Picture Formats

Image Magic Bytes: Verify the Format Before Trusting the Extension

A file name is a label. Opening bytes, declared brands, internal boundaries, and a successful decode establish which image format the supplied bytes actually support.

  • Court qualified expert witnesses
  • Former law enforcement forensic examiners
  • Hash verified chain of custody
  • Nationwide support for attorneys and clients

Home › Digital Evidence Authentication › Photo and Image Authentication › Image Magic Bytes and File Signatures

Quick Answer. Image magic bytes are recognizable byte sequences used to identify an encoding independently of its file name. JPEG normally begins FF D8, PNG has an eight byte signature, and WebP uses RIFF with WEBP at offset eight. HEIC identification requires inspecting ftyp brands. A signature match is a starting classification that must be confirmed by structural parsing and decoding.

This format identification guide belongs to Photo and Image Authentication. It precedes the detailed container structure examination and helps choose the correct metadata interpretation. Signature checks answer what kind of object was supplied. They do not answer who made its pixels, whether its date is accurate, or whether the pictured scene occurred. Record the bytes first and treat application labels as a separate observation.

JPEG opening pairFF D8 introduces a JPEG codestream.
PNG opening octet set89 50 4E 47 0D 0A 1A 0A identifies PNG.
WebP type positionWEBP occurs at byte offset eight in its RIFF container.
HEIF brand inspectionRead ftyp brand values rather than trusting HEIC naming.

Image signature identification answers

QuestionShort answer
What are JPEG magic bytes?FF D8 is the start of image marker. A following legal marker and valid segments strengthen the identification; FF D8 alone is too short for a complete validation.
What are PNG magic bytes?The signature is 89 50 4E 47 0D 0A 1A 0A. Confirm an IHDR chunk follows and that chunk lengths, checksums, and image decoding are coherent.
Where are HEIC magic bytes located?HEIC commonly has an ftyp box type at offset four, followed by a major brand, minor version, and compatible brands. The brands distinguish relevant HEIF profiles.
What are GIF magic bytes?The complete header is GIF87a or GIF89a, beginning 47 49 46 38. Logical screen and block parsing must follow the version header.
How do WebP magic bytes differ from AVI?Both use RIFF at offset zero. WEBP at offset eight identifies WebP, whereas AVI uses a different RIFF form type. RIFF alone is insufficient.
Can TIFF magic bytes identify byte order?Yes. Classic TIFF starts with II and little endian 42 or MM and big endian 42. The offset to its first image file directory follows.

Key terms defined

SOI signature pair

The JPEG FF D8 bytes that introduce the codestream.

RIFF form type

The four character value at offset eight identifying the RIFF content family, such as WEBP.

ftyp compatible brand

A four byte identifier declaring a format family that a base media file is compatible with.

GIF version header

The six ASCII bytes GIF87a or GIF89a identifying a GIF version.

TIFF byte order marker

The opening II or MM characters specifying the order used for multibyte TIFF values.

Embedded signature hit

A matching byte sequence found inside another object that requires context before classification.

Which opening bytes identify common image formats?

Use absolute byte offsets measured from zero. A name ending in .jpg can carry PNG data, and a name ending in .heic can carry a converted JPEG. The extension does not change the underlying encoding. Inspect enough bytes to recognize both the container and its subtype before selecting a parser.

Candidate formatExpected bytesPosition and confirmation
JPEGFF D8Offset zero, then a coherent marker sequence
PNG89 50 4E 47 0D 0A 1A 0AOffset zero, then IHDR
GIF87a47 49 46 38 37 61Offset zero, then logical screen descriptor
GIF89a47 49 46 38 39 61Offset zero, then logical screen descriptor
WebP52 49 46 46 and 57 45 42 50RIFF at zero and WEBP at eight
Classic TIFF49 49 2A 00 or 4D 4D 00 2AOffset zero, followed by a valid directory offset

Use complete signatures where available

The four bytes 47 49 46 38 identify the beginning of a GIF header, but the remaining version characters still matter. Likewise, PNG deliberately includes bytes that help detect certain transfer transformations. A partial match that omits the carriage return, line feed, or final line feed is not a match to the complete PNG signature.

JPEG commonly carries JFIF in APP0 or Exif in APP1, but neither arrangement is universal. Requiring every JPEG to start FF D8 FF E0 rejects valid Exif oriented files and other legitimate layouts. Confirm SOI, then parse the actual markers. Our structure guide explains why length aware parsing is more reliable than searching for one familiar prefix.

Classic TIFF byte order determines how subsequent offsets and tag values are read. BigTIFF uses a different version value and additional offset size fields; do not apply the classic TIFF directory layout indiscriminately. A classification report should say which variant was recognized and whether the supported parser validated that variant.

Resolve a format mismatch before converting the file

We identify the supplied encoding without rewriting it, then document whether the name, application label, and actual content agree.

Request Confidential Consultation Call (833) 292 3733

Why does HEIC identification require more than ftyp?

The ASCII sequence 66 74 79 70 spells ftyp. In a conventional first box it occurs at offset four, after the box size. This identifies a file type box in the ISO base media family, which includes many image and video formats. It does not by itself identify a still photograph.

FieldExampleInterpretation
Box typeftypA format declaration box, not a camera identifier
Major brandheicA HEIF profile associated with HEVC coded images
Compatible brandmif1Compatibility with a generic HEIF image structure
Other image brandavifAn AV1 image format declaration requiring its own interpretation
Following metadatameta with item descriptionsEvidence needed to locate and reconstruct image items

Brands describe compatibility, not origin

A file can declare several compatible brands. Record the major brand, minor version, and complete compatible brand list instead of selecting the first familiar four characters found by text search. Respect the ftyp box boundary: a brand looking string in unrelated metadata is not a declaration.

A brand string also does not establish that a specific manufacturer created the file. Many applications can encode compatible files, and conversions can preserve or reconstruct metadata. Device attribution needs evidence beyond format naming. A well formed ftyp with broken item references may identify an intended format even when the primary picture cannot be decoded.

Use cautious precision in the result: the bytes declare HEIF compatibility under specified brands, the parser locates specified image items, and the decoder succeeds or reports a particular failure. That statement is reproducible. Calling any file containing ftyp an original iPhone photograph is not.

What do image closing markers and trailing bytes reveal?

A closing marker helps determine where one encoded object ends. JPEG uses EOI, FF D9. PNG ends with an IEND chunk whose data length is zero. GIF uses a trailer byte 3B after the final block sequence. WebP relies on the RIFF size and chunk boundaries rather than a JPEG style end marker.

Locate the terminator by parsing

An apparent FF D9 inside a thumbnail is not necessarily the end of the main JPEG. A semicolon byte inside compressed GIF data is not necessarily a trailer. A literal IEND string in text is not the closing PNG chunk. Establish context and boundaries before describing bytes as appended. The JPEG scan discussion also explains entropy data rules that affect marker interpretation.

After the real endpoint, record the number of remaining bytes, their offsets, and their content. Repeated zero values can be padding. A second recognizable object may be an embedded attachment, a constructed composite file, or a concatenation artifact. The observation should distinguish what was found from why it was placed there.

  • Retain the entire supplied file, including material ignored by ordinary viewers.
  • Extract trailing ranges into separate working artifacts without trimming the evidence copy.
  • Identify whether an extracted resource independently parses and decodes.
  • Compare other copies to determine whether the extra range existed before collection.

A valid prefix followed by incomplete payload is not a complete valid image. Conversely, an intact image followed by extra bytes may display normally. These are different findings. The report should state whether the image decodes, whether its container conforms, and whether unexplained material remains beyond its normal endpoint.

How should examiners handle renamed and mixed format files?

An extension mismatch is a reason to classify the bytes, not a finding of deception. Browser downloads, email systems, document exports, and user renaming can produce mismatches. Preserve the supplied name as evidence while using the detected encoding for analysis. If a working copy needs a corrected extension, record that change without modifying its content.

Do not confuse embedding with polyglot construction

A JPEG containing an Exif thumbnail has nested image data as a normal feature. An archive containing pictures is an archive with image members. A polyglot is constructed to satisfy more than one format interpretation as a single object. Establish both interpretations through parsing rather than declaring a polyglot because two signature strings were found.

Signature scanners can also report chance matches in compressed or encrypted data. The shorter the pattern, the less persuasive a standalone hit becomes. Record candidate offsets and test each candidate against plausible lengths, required records, and a full decode. A database label should not replace the supporting byte observations.

For safety, examine unknown files in a controlled environment and avoid relying on application launch behavior as the format test. A familiar icon or successful preview can be generated by cached information, an embedded preview, or a tolerant decoder. The forensic finding should describe the actual supplied stream, not the desktop's interpretation of its name.

When two detectors disagree, retain their names and versions in the working record, inspect the disputed bytes, and identify the rule behind each result. One detector may report the outer container while another reports an embedded image. Both labels can be understandable once their scope is made explicit.

Identify an unknown image from bytes to decode

This procedure produces a format finding with exact offsets and preserves mismatches for later explanation.

  1. Record the received image label. Capture the complete file name, size, source, and SHA256 digest. Keep the supplied extension even when it appears wrong.
  2. Read the opening signature range. Inspect the first bytes and any required subtype positions. Record hex values without assuming that RIFF or ftyp alone identifies a photograph.
  3. Validate format specific declarations. Check JPEG marker order, PNG IHDR placement, TIFF byte order, GIF version, WebP form type, or HEIF brand boundaries.
  4. Follow the actual closing boundary. Parse to EOI, IEND, GIF trailer, declared RIFF extent, or the relevant base media box boundaries. Inventory any remaining material.
  5. Attempt a complete controlled decode. Use software supporting the detected format and record warnings, dimensions, frames, or items. Do not accept a cached thumbnail as full validation.
  6. Report classification and mismatch separately. State the encoding supported by the bytes, the supplied extension, and the evidence for any embedded or appended objects.

What matters most

  • A received file named evidence.jpg has the complete PNG signature.
  • A detector labels an ftyp based still image as a generic media container.
  • A JPEG carries an unexplained second object beyond the parsed EOI.
  • An image preview succeeds while the primary stream is truncated.
  • A signature scan reports a thumbnail as though it were a separate supplied picture.

Common misconceptions

  • Every JPEG starts with the same APP0 prefix. Valid JPEG layouts need not place JFIF APP0 immediately after SOI.
  • The ftyp bytes uniquely identify HEIC. Many base media formats use ftyp. Brands and image structure refine identification.
  • A wrong image extension proves concealment. Renaming and export behavior can produce innocent mismatches. Explain the route where records allow.
  • Finding two image signatures proves a polyglot. Normal previews and chance matches also produce multiple hits. Validate distinct format interpretations.

When this applies, and when it does not

This applies when

  • Unknown picture attachments and renamed files
  • Raw signature checks for common still image families
  • Image end boundary and trailing range inventories
  • Disagreements between format identification systems

This does not apply when

  • Device attribution from a brand string alone
  • Visual authenticity from a valid opening signature
  • Malicious intent inferred solely from a file extension

How Elite Digital Forensics helps

We verify actual image encodings, reconcile detector results, and document nested or trailing objects without confusing classification with authenticity. This analysis is led by subject matter experts in file signature analysis who confirm whether an image is the format it claims to be.

About Elite Digital Forensics

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.

Related Digital Forensics Resources

Questions about identifying image bytes in evidence

Can image magic bytes survive a file rename?

Yes. Renaming changes the label, not the internal bytes. The signature remains unless software actually converts or rewrites the content.

Are image magic bytes enough to recover a deleted photo?

They can identify a candidate start in recovered storage. Recovery also needs sufficient payload and structural continuity; fragmented data may require additional reconstruction.

Why can image signature software identify a file that will not open?

The opening pattern may survive while required data is missing or damaged. Signature identification and successful decoding are separate tests.

Do image magic bytes reveal a camera serial number?

No. A format signature is not a device identity. Serial number claims, when present, reside in metadata and require independent evaluation.

Can image magic bytes distinguish a screenshot from a camera photo?

Not reliably. Both can use JPEG or PNG. Dimensions, metadata, pixel characteristics, and source records address the capture pathway.

Should image signature testing change the file extension?

Not on the preserved original. A separately documented working copy can use an appropriate extension if analysis software requires it.

Classify the bytes before interpreting the picture

A useful signature finding includes the observed values, their offsets, the structural confirmation, and the decode result. Keep format identity separate from claims about the photographer or scene. Our court qualified experts in photo forensics can testify to what the header bytes prove.

Request Confidential Consultation Call (833) 292 3733

Primary sources and references

  1. Gary Kessler, File Signatures Table. www.garykessler.net
  2. ITU T.81 and ISO/IEC 10918 1, Digital Compression and Coding of Continuous Tone Still Images (JPEG). www.w3.org
  3. W3C, Portable Network Graphics (PNG) Specification, Third Edition. W3C PNG Specification, Third Edition
  4. Google for Developers, WebP Container Specification (RIFF). developers.google.com
  5. W3C hosted copy, Graphics Interchange Format Version 89a specification. www.w3.org
  6. Library of Congress, Sustainability of Digital Formats, TIFF, Revision 6.0. www.loc.gov
  7. Library of Congress, Sustainability of Digital Formats, High Efficiency Image File Format, HEIC brands. www.loc.gov

This 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.

#DigitalForensics #ComputerForensics #CellPhoneForensics #ExpertWitness #DigitalForensicExperts #EliteDigitalForensics #ForensicInvestigation #CriminalDefenseForensics #ImageSignatures #MagicBytes #FormatIdentification #JPEGHeader #PNGSignature #ByteVerification

Assistant Icon Elite Digital Forensics Assistant
πŸ‘‹ Live Chat Now!
Free Virtual Consultation 24/7
Chat Now!

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