DjVu File Format Explained: Why Scanned Pages Stay Small

DjVu was engineered around a scan's separate visual jobs

DjVu, pronounced like "deja vu," is a document format made for scanned pages, high-resolution images, and online delivery. AT&T Labs published the first version in 1998; the published format specification was later revised in 2005. It is often encountered in digitized books, journals, technical papers, maps, and historical material because a page that looks like a large photograph to a computer can be treated as several different kinds of visual information. DjVu does not assume that the small black letters, a pale paper background, and a color photograph deserve the same compression method. It separates them before encoding, which is the central reason many scan-heavy DjVu files are smaller than a simple one-image-per-page alternative.

That design is different from the everyday idea of a word-processing document. A DjVu page is normally a rendered page image, not a collection of editable paragraphs, even when it contains a searchable text layer. The visible letters may be pixels from a scan; the selectable words beneath them may have been produced by OCR and can contain recognition mistakes. This is why changing DjVu to DOCX does not recover the original typing or its styles. The practical choice is usually between keeping the DjVu as the archival scan, creating a PDF for easier viewing, or extracting and proofreading text for a genuinely editable copy.

Inside a DjVu page: masks, backgrounds, and chunks

At file level, DjVu uses an Interchange File Format-style chunk structure. Its first four bytes are the ASCII marker AT&T, followed by a FORM chunk. A single page is identified as FORM:DJVU; a multi-page document uses FORM:DJVM. In a normal page, the first nested chunk is INFO, which records page width, height, format version, resolution, gamma, and rotation. This is useful when a file fails to display correctly: DjVu is not just a renamed JPEG or PDF, and a reader that does not understand these chunks cannot infer the page from its extension.

A compound page can use a high-resolution black-and-white mask for text and line art, plus lower-resolution foreground and background color layers. The mask is usually stored in an Sjbz chunk using JB2 data compressed with BZZ; repeated letter shapes can be represented efficiently instead of keeping a full-color pixel record for every mark. Background and foreground layers use the IW44 wavelet encoder in BG44 and FG44 chunks. Optional TXTz or TXTa chunks carry Unicode text and layout information; NAVM can carry a compressed outline for a multi-page file. In short, visible pixels, hidden reading text, bookmarks, and page directory data can be separate components. Losing one component does not necessarily mean the others are gone.

A multi-page document can also share data between pages. Its FORM:DJVM container starts with a DIRM directory that identifies component pages, and a FORM:DJVI component can hold shared material referenced by individual pages through INCL. A document may be bundled into one file or arranged as indirect component files. That detail explains a real failure mode with partial downloads or copied folders: a viewer can show a directory yet fail on pages whose referenced components are absent. A PDF conversion can hide this distinction by producing a single ordinary PDF, but that does not repair an incomplete DjVu source.

Why a 300 dpi book can stay comparatively small

• Gain - sharp small text: the bitonal mask can keep letters and line work at high resolution while the paper background is stored at a lower resolution.
• Gain - efficient repeated shapes: JB2 can reuse a shape dictionary for repeated glyph-like marks, which is well suited to printed pages.
• Gain - progressive display: DjVu was designed for web delivery, so a viewer can begin showing a page before all image detail has arrived.
• Gain - optional search and outline data: text and bookmark chunks can make a scanned book searchable without replacing its visible page image.
• Loss - a specialized reader requirement: browsers and mainstream office suites do not treat DjVu as a routine document format, unlike PDF.
• Loss - irreversible image decisions: the IW44 foreground and background compression is lossy, so converting to a larger format cannot restore scan detail that was discarded when the DjVu was made.

The often-repeated claim that DjVu is "better than PDF" is too broad. DjVu is particularly efficient for scanned pages built from text, paper texture, and occasional pictures. A born-digital PDF with vector text, selectable drawing objects, and embedded fonts is a different kind of document and should usually stay PDF. DjVu's strength appears when the source is already page imagery. It can make a 300 dpi scan readable and compact, but it cannot turn a poor scan, a blurred original, or wrong OCR into accurate source text.

Where DjVu still opens without a browser plug-in

DjVuLibre is the open-source reference implementation and includes the DjView viewer, decoders, simple encoders, and command-line utilities. Its DjView4 application is available for Unix-like systems, Windows, and macOS builds. On Windows, WinDjView and SumatraPDF are common viewer choices; on Linux, Okular and several other multi-format document viewers can open DjVu. The exact feature set matters: opening a page, copying its hidden text, following a hyperlink, and exporting a PDF are separate capabilities. A viewer may show the scanned image perfectly while exposing none of the text layer to a printer or export tool.

Do not expect a current web browser to render a DjVu attachment as naturally as a PDF. Older browser plug-ins existed, but plug-in support is not a dependable current route. Open the file in a dedicated reader first. If the only need is reading, that avoids conversion damage altogether. If a PDF is required, DjVuLibre's ddjvu command recognizes pdf as an output format, but its manual describes it as a decoder producing image output. That distinction matters because a convenient PDF result may be a raster rendering of each page rather than a faithful transfer of every DjVu component.

Searchable text and page pixels are not the same layer

Search finds nothing although the page clearly contains words. The file may have no TXTz/TXTa text component; it may be a scan with only image layers. OCR is needed to create a new text layer, and the result must be proofread. Search works, but copied text is nonsense. The hidden layer can contain old OCR mistakes, incorrect reading order, or an unsuitable language setting. The visible page has not necessarily changed; the pixel image and the machine-readable text are separate evidence. Compare a few copied paragraphs to the page before relying on the output for citations or search.

One page is blank or has the wrong rotation. Check it in a second DjVu reader before treating the file as corrupt. The INFO chunk records rotation and display properties, and reader support can differ. A damaged multi-page document may also have a problem only in one component page. DjVuLibre's decoder includes a -skip option to skip corrupted pages instead of aborting a decoding run, which can help recover readable pages while isolating the bad one. Preserve the original before any repair or conversion, because re-encoding can make a later byte-level diagnosis impossible.

The cover opens, but later pages report missing data or fail only after the file was moved. First determine whether it is an indirect document, not a self-contained download. In that arrangement the index file holds the directory and addresses of separate page files; the DjVuLibre manual says a viewer fetches data for the pages being viewed and may cache or pre-fetch nearby pages. Copying only that small index, renaming its folder, or downloading it without its companions therefore leaves valid references pointing at absent files. If the source is still available, copy the complete directory unchanged, or use djvmcvt -b to make a bundled document before sharing it. For an image-only diagnosis, ddjvu can render mask, foreground, or background separately; a selected-layer failure shows that the missing or damaged piece is not the hidden OCR text.

DjVu compared with PDF at the scanned-page boundary

Questions before keeping a document as DjVu

Is DjVu just a PDF with another extension?
No. DjVu has its own chunk structure and a page model built around compressed scan layers. Renaming it to PDF will not make a PDF reader understand it.

Why can I see text but not select it?
The visible characters may be only scan pixels. Search and selection require an optional hidden text layer, which a file may not contain.

Does a larger converted image improve scan quality?
No. Enlargement adds pixels but cannot restore detail already removed by the original scan or by lossy IW44 image compression.

Should a multi-page DjVu be kept after making a PDF?
Yes. The DjVu may retain its compact layer structure, outline, and original hidden text even if a quick PDF conversion flattens or omits some of them.