DJVU File Documentation
Summary
A DjVu file (pronounced “déjà vu”) is a compact scanned-document image, typically a book, journal or archived paper stored as page images plus an optional hidden text layer. Developed at AT&T Labs in 1996, it makes scanned pages far smaller than an equivalent PDF by compressing text and background separately. Open a .djvu file with a free reader such as SumatraPDF or WinDjView; its MIME type is image/vnd.djvu. The most common request is converting DjVu to PDF so it opens everywhere.
Technical details
| Feature | Value |
|---|---|
| Full name | DjVu Document |
| File extension | .djvu (also .djv) |
| MIME type | image/vnd.djvu |
| Format type | Layered, compressed scanned-document image container |
| Category | eBook / scanned document |
| Developer | AT&T Labs Research; later LizardTech / Caminova; open tools by DjVuLibre |
| Introduced | 1996 |
| Container base | IFF85 (Interchange File Format, EA/Amiga style) |
| Byte order | Big-endian (IFF chunk sizes) |
| Magic number | 41 54 26 54 (ASCII AT&T) at offset 0, then FORM |
| Form type | DJVU (single page) or DJVM (multi-page bundle) |
| Text/mask compression | JB2 (bilevel, soft pattern matching) in the Sjbz chunk |
| Background compression | IW44 wavelet in BG44 / FG44 chunks |
| Text layer | Optional OCR, BZZ-compressed, in TXTz |
| Open standard | Partial — published spec, open DjVuLibre tools; format history proprietary |
| Free readers | SumatraPDF, WinDjView, DjView, Okular, MacDjView |
| Convert with | DjVuLibre (ddjvu, djvutxt), Okular / WinDjView (print to PDF) |
| Related extensions | .djv, .pdf, .tiff |
| Specification | djvu.org/resources/ |
What is a DjVu file?
DjVu (pronounced “déjà vu”) is a document-image format created at AT&T Labs Research in 1996 to store high-resolution scanned pages at a fraction of the size of a PDF or TIFF scan. Its target was the scanned book: a page that must stay sharp enough to read small type, yet small enough to download over a slow link. DjVu reaches that goal by treating a scanned page not as one flat image but as several layers, each compressed with an algorithm suited to what it contains.
The technology passed from AT&T to LizardTech and later Caminova, while the open-source DjVuLibre project keeps free encoders, decoders and the DjView viewer maintained. In practice you meet .djvu files as scanned books, old journals, technical manuals and public-domain texts from digital libraries, with especially strong use in academic and Eastern-European collections. The format peaked in the 2000s; PDF is now far more widely supported, so the dominant user need is either to read a DjVu or convert it to PDF. The registered MIME type is image/vnd.djvu.
The IFF container: AT&T, FORM, and big-endian chunks
A DjVu file is an IFF85 document, the same chunk-based container family used by Amiga IFF and EA formats. It begins with the 4-byte tag AT&T (41 54 26 54), which is not itself an IFF chunk but a marker identifying the file as DjVu. Immediately after comes a standard IFF structure. Every chunk has an identical 8-byte header:
BYTE[4] chunk ID e.g. "FORM", "INFO", "Sjbz", "BG44"
BE32 data length big-endian 32-bit, size of the data only (not the header)
BYTE[] chunk data 'length' bytes
[pad] one 0x00 byte if 'length' is odd, to keep chunks 16-bit aligned
The outermost chunk is always FORM, and the first four bytes of its data are a secondary identifier: DJVU for a single page or DJVM for a multi-page bundle. Because the length field is big-endian, DjVu is one of the formats where the size bytes read naturally left to right, unlike the little-endian ZIP or Quake PAK. Chunk data is byte-aligned and padded to an even length, so a reader that does not recognise a chunk can skip exactly length (plus a possible pad byte) and continue — the same forward-compatibility trick IFF and later box formats rely on.
DJVU and DJVM: single page versus bundle
A single scanned page is a FORM:DJVU whose first nested chunk must be INFO. A whole scanned book is a FORM:DJVM (multi-page), which opens with a DIRM directory chunk listing every page component and where it lives, so a reader can jump to page 300 without decoding the first 299. DJVM bundles can either embed each page’s data (bundled) or reference external page files (indirect). The DIRM also enables shared components: a repeated element such as a common letter shape can be stored once and reused across pages, which is part of why multi-page DjVu stays small.
Layered compression: the foreground mask, the background wavelet
The core idea of DjVu is to split each page into a sharp foreground mask and a smooth background, then compress each with a different algorithm. Text and line art are mostly black on white and need crisp edges; the paper texture, illustrations and colour bleed behind them are smooth and tolerate lower resolution. Storing them together as one image wastes bits; storing them apart is DjVu’s whole trick.
INFO page dimensions, DPI, DjVu version, gamma (must come first)
Sjbz the bilevel text/line MASK, JB2-compressed (full resolution)
BG44 the BACKGROUND layer, IW44 wavelet (lower resolution)
FG44 the FOREGROUND colours, IW44 wavelet (optional, sub-sampled)
FGbz per-shape colour for the JB2 mask (optional)
TXTz hidden OCR text + layout, BZZ-compressed (optional)
ANTz annotations: hyperlinks, highlights, metadata (optional)
The INFO chunk records the page width and height in pixels, the resolution in DPI, the format version and a gamma value, and it must be the first chunk inside FORM:DJVU so a decoder knows the page geometry before reading pixel data.
JB2: the bilevel mask in the Sjbz chunk
The Sjbz chunk holds the page’s black-and-white mask, compressed with JB2, a variant of the JBIG2 approach. JB2 uses soft pattern matching: it finds repeated shapes on the page (the letter “e” appears hundreds of times), stores one representative bitmap for each shape in a shared dictionary, and then records the positions where each shape recurs. Small differences between instances are coded as residuals rather than stored in full. This is extremely efficient for printed text, where a page is thousands of copies of a few dozen glyph shapes, and it is the main reason a DjVu book is smaller than a PDF that stores every page as one flat image.
IW44: the wavelet background
The BG44 chunk stores the page background — paper colour, photographs, shading — using IW44, a wavelet image representation. Wavelet coding lets the background be encoded at a lower resolution than the text mask (often one third), because the eye does not need the background as sharp as the lettering, and it supports progressive refinement: multiple BG44 chunks in sequence add successive detail, so a viewer can display a coarse page quickly and sharpen it as more data arrives. When the mask itself is coloured (not pure black), an FG44 foreground-colour layer and an FGbz per-shape palette add the colour back to the JB2 shapes.
The hidden text layer and why search works
A DjVu made from a scan is fundamentally page images, so on its own it has no machine-readable text. Many DjVu files add a TXTz chunk containing an OCR text layer: the recognised characters together with the bounding box of each word or line, compressed with the BZZ (a Burrows-Wheeler) coder. This is what lets a reader search the document, copy text, and map a click on a word to its position. When people ask to “extract text” or “convert DjVu to TXT”, they are really asking to pull out this layer: DjVuLibre’s djvutxt reads it directly. If a file has no TXTz chunk, there is no text to extract and the page must be run through OCR (for example Tesseract) first. Annotations — hyperlinks, highlights and metadata — live in a separate ANTz chunk.
Reading DjVu and converting to PDF
Reading needs no conversion: PDF reader SumatraPDF also opens DjVu, and WinDjView, DjView, KDE Okular and MacDjView are dedicated readers. The near-universal request is DjVu to PDF, so the file opens on any phone or e-reader. DjVuLibre does this from the command line with ddjvu -format=pdf in.djvu out.pdf, or you can open the file in Okular, SumatraPDF or WinDjView and print to PDF. The resulting PDF keeps the scanned page images and the OCR text layer if one was present, but it is usually larger than the DjVu, because PDF does not use DjVu’s layered mask-plus-wavelet split. Exporting to TIFF (ddjvu -format=tiff) or to JPG per page is possible for archival pipelines, at a further size cost. A faithful reflowable EPUB is only achievable through OCR, since the source is images, not text.
DjVu is document-image data and is safe to open in a reputable reader; it cannot run macros or code. The only real caution is to download the reader from the official project (DjVuLibre on SourceForge, SumatraPDF, WinDjView) rather than ad-laden mirror sites, and to treat embedded hyperlinks with the usual care.
Frequently asked questions
How do I convert DjVu to PDF?
Open it in Okular, SumatraPDF or WinDjView and print to PDF, or use DjVuLibre’s command line: ddjvu -format=pdf book.djvu book.pdf. The PDF keeps the scanned pages and any searchable text layer, but is normally larger than the DjVu.
Why is a DjVu smaller than the same PDF scan?
DjVu splits each page into a sharp JB2 text mask and a low-resolution IW44 wavelet background and compresses each separately, and it reuses repeated glyph shapes from a shared dictionary. A plain PDF scan stores the whole page as one image, so it is bigger.
Can I extract or search the text in a DjVu?
Only if the file has an OCR text layer (the TXTz chunk). If it does, DjVuLibre’s djvutxt extracts it and the reader’s search works. If there is no text layer, the pages are just images and you must run OCR, such as Tesseract, first.
Are .djvu and .djv the same?
Yes. They are identical files, just two spellings of the extension — the short .djv is a DOS three-letter leftover. You can rename one to the other freely; no conversion is involved.
References
- DjVu.org — format resources and specification
- DjVuLibre — free DjVu tools (DjView, ddjvu, djvutxt)
- Library of Congress — DjVu format description
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.