EMZ File Documentation

Summary

An EMZ file is a Windows Compressed Enhanced Metafile: an EMF vector image compressed with GZIP, the same relationship SVGZ has to SVG. It stores GDI drawing commands (lines, curves, text, embedded bitmaps) used mainly by Microsoft Office and Visio, and often turns up as the image001.emz attachment in Outlook mail. The extension is .emz; the payload MIME is image/emf inside an application/gzip wrapper. Decompress it with 7-Zip or gunzip to get a plain .emf.

Technical details

FeatureValue
Full nameWindows Compressed Enhanced Metafile
File extension.emz
MIME typeimage/emf payload inside application/gzip
Format typeGZIP-compressed EMF vector image
Container / base formatGZIP stream (RFC 1952) wrapping one EMF file
Payload formatEMF (Enhanced Metafile) — a stream of GDI records
DeveloperMicrosoft
IntroducedLate 1990s (Office/Visio); EMF itself in Windows NT 3.1, 1993
Standard / specMS-EMF (Enhanced Metafile Format); RFC 1952 for the GZIP wrapper
Open standardPartial — EMF documented as MS-EMF; wrapper is standard GZIP
Byte orderLittle-endian
Magic number (hex)1F 8B 08 (GZIP, deflate method)
Payload signatureEMF dSignature = 20 45 4D 46 (“ EMF”) at offset 40 of the decompressed EMF
Vector or rasterVector (GDI drawing commands); may embed raster bitmaps
ContentPaths, pens, brushes, text with fonts, transforms, embedded DIBs
TransparencyLimited — depends on GDI records used
Created byMicrosoft Visio, Word, PowerPoint, Outlook (RTF mail)
EditableAfter decompression, in Inkscape / LibreOffice Draw
Related extensions.emf, .wmz, .wmf, .svgz, .svg
Specificationlearn.microsoft.com/openspecs/windows_protocols/ms-emf
File signature (magic bytes)
1F 8B 08

Offset 0, 3 bytes. 1F 8B is the GZIP magic number (RFC 1952) and 08 is the deflate compression method, because an EMZ is simply an EMF file inside a single-member GZIP stream. The vector image only appears once you decompress it: the recovered .emf begins with the record type 01 00 00 00 (EMR_HEADER) at offset 0, and carries the EMF signature 20 45 4D 46 (the little-endian dSignature 0x464D4520, ASCII “ EMF”) at offset 40. Rename the file to .emf.gz and any GZIP tool unpacks it losslessly.

What is an EMZ file?

EMZ stands for Enhanced Metafile Compressed: it is a standard Windows Enhanced Metafile (EMF) wrapped in GZIP compression. It is not a separate image format at all. The relationship is exactly that of SVGZ to SVG, or WMZ to WMF: take the vector file, run it through GZIP, and the result is the compressed .z variant. Decompress an EMZ and you get back a byte-identical EMF.

EMF, the payload format, was introduced with Windows NT 3.1 in 1993 and is documented in Microsoft’s open MS-EMF specification. It stores a recorded sequence of GDI (Graphics Device Interface) drawing commands: move the pen here, draw a curve there, select this brush, place this text run in that font. Because those are drawing instructions rather than a grid of pixels, an EMZ is usually a scalable vector graphic (a diagram, chart, logo or piece of clip art), though EMF records can also embed raster bitmaps. Everything below is about the two layers: the GZIP wrapper and the EMF record stream inside it.

The GZIP wrapper: RFC 1952 and the 1F 8B header

The outer layer of every EMZ is a single-member GZIP stream as defined by RFC 1952. Its first two bytes are the GZIP magic number 1F 8B, followed by the compression method byte, which is always 08 (deflate) in practice.

Offset  Size  Field
0       2     ID1 ID2   = 1F 8B   (GZIP magic)
2       1     CM        = 08      (deflate)
3       1     FLG       flags (FNAME, FHCRC, ... usually 0)
4       4     MTIME     modification time (little-endian)
8       1     XFL       extra flags
9       1     OS        source operating system
10+     ...   compressed EMF data (deflate stream)
end-8   4     CRC32     of the uncompressed EMF
end-4   4     ISIZE     uncompressed size mod 2^32

Because the wrapper is nothing more than ordinary GZIP, any GZIP-aware tool decompresses an EMZ without special handling. Renaming picture.emz to picture.emf.gz and running gunzip, or right-clicking → 7-Zip → Extract, yields the raw EMF. The final eight bytes carry a CRC32 of the decompressed data and its length modulo 232, so a truncated EMZ can be detected before its contents are trusted.

The EMR_HEADER record: bounds, frame and the EMF signature

Once decompressed, the EMF is a flat sequence of records, and the very first record is always EMR_HEADER. It describes the whole picture before any drawing happens: its type, its size, the bounding rectangle of the image in device units, the physical frame in units of 0.01 mm, and the counts a parser needs to walk the file.

EMR_HEADER (first record of the decompressed EMF)
  iType       : uint32  = 0x00000001   (record type = EMR_HEADER)
  nSize       : uint32                 (size of this record in bytes)
  rclBounds   : RECTL   (4 x int32)    device-unit bounding box
  rclFrame    : RECTL   (4 x int32)    frame in 0.01 mm units
  dSignature  : uint32  = 0x464D4520   ASCII " EMF"  (offset 40)
  nVersion    : uint32                 metafile version
  nBytes      : uint32                 total size of the metafile
  nRecords    : uint32                 number of records in the file
  nHandles    : uint16                 size of the GDI handle table

The field that positively identifies an EMF is dSignature at byte offset 40 (0x28): the 32-bit little-endian value 0x464D4520, which spelt out in file order is 20 45 4D 46, the ASCII string “ EMF”. nRecords tells a reader how many records follow, and nHandles sizes the handle table that the record stream fills as it selects pens, brushes and fonts. rclFrame in 0.01 mm units is what makes the metafile resolution-independent: a renderer scales the device-unit geometry into that physical frame.

The GDI record stream: pens, brushes, paths and text

After the header, the EMF is a list of GDI records executed in order, each a small structure beginning with its own iType and nSize. The renderer maintains a graphics state (current pen, brush, font, transform) and each record either changes that state or draws with it. This is why the format is compact and scalable: it replays the exact GDI calls the creating application made.

RecordWhat it does
EMR_CREATEPEN / EMR_CREATEBRUSHINDIRECTDefine a pen or brush and put it in the handle table
EMR_SELECTOBJECTMake a handle-table object the current pen/brush/font
EMR_MOVETOEX / EMR_LINETO / EMR_POLYBEZIERMove the current point and draw straight or Bézier geometry
EMR_EXTTEXTOUTWDraw a Unicode text run with per-character spacing
EMR_STRETCHDIBITSBlit an embedded device-independent bitmap (raster inside the vector)
EMR_EOFEnd-of-file marker terminating the record stream

Text is stored as real Unicode via EMR_EXTTEXTOUTW, so an EMZ carrying a labelled diagram keeps its text as characters, not outlines. Raster content is not excluded: an EMR_STRETCHDIBITS record can embed a full bitmap, which is why some EMZ files are effectively compressed wrappers around a raster image rather than pure line art.

Why Outlook produces image001.emz

The most common way people meet an EMZ is as an email attachment named image001.emz that their non-Microsoft mail client cannot display. This happens when the sender’s Outlook composes the message in Rich Text (RTF) rather than HTML. Outlook converts inline graphics in RTF mail into metafiles and attaches them, so a signature logo or pasted diagram arrives as an EMZ (alongside the familiar winmail.dat in the same scenario). The image is usually decorative, which is why it can often be ignored; the sender-side fix is to compose messages as HTML instead of Rich Text.

The second common source is unpacking an Office document. A DOCX or PPTX is itself a ZIP package, and pasted vector graphics are stored inside it as EMZ files under word/media/ or ppt/media/. Extracting the document with any ZIP tool exposes those EMZ parts directly.

Rendering depends on GDI, and on a patched parser

Because EMF is a recording of GDI calls, faithful rendering historically depended on the Windows GDI itself, which is why EMF/EMZ display on macOS and Linux is approximate and best handled by tools with their own interpreters (LibreOffice Draw, Inkscape) rather than a GDI shim. The same parsing surface has a security history worth noting: Windows metafile handling produced the WMF vulnerability of 2005–2006 and a recurring series of GDI/EMF parsing flaws since. The records are pure drawing data with no macros or scripting, so the realistic risk is a malformed metafile exploiting a bug in the renderer, not executable payload in the file. Keeping Windows and Office patched is the mitigation; a normal image001.emz from routine business mail is a harmless Outlook artefact.

Deep questions about the EMZ format

What exactly is the difference between EMZ and EMF?

None in the image itself. EMZ is an EMF compressed with GZIP; decompressing it reproduces the original EMF byte for byte. The conversion is lossless and instant in both directions, which is why “convert EMZ to EMF” is really just an extraction with 7-Zip or gunzip, not a re-encode.

Is an EMZ always a vector image?

Usually, but not necessarily. The EMF record stream is made of GDI drawing commands, which are vector by nature and scale cleanly. However, an EMR_STRETCHDIBITS record can embed a raster bitmap, so an EMZ that wraps a pasted screenshot is effectively a compressed raster image dressed as a metafile.

References