Convert Documents and Images to DJVU: Pick the Right Source
What a real conversion to DjVu builds, why scanned pages are its natural input, and how to avoid losing searchable text on the way.
- Add a file Choose or drop it here
- Pick the format Change it whenever needed
- Download the result After conversion completes
Making DjVu begins with a page image, not a document extension
A conversion to .djvu is most useful when the source is a scanned page or a page image that needs compact storage. DjVu was developed at AT&T Labs between 1995 and 1999 for fast delivery of scanned documents and high-resolution images. It is not a general-purpose replacement for DOCX, ODT, HTML, or a born-digital PDF. The destination is built around a rendered page: a DjVu document can store a foreground mask, a background image, optional color information, optional hidden text, thumbnails, and an outline. The file therefore preserves the appearance of a page far more naturally than the editable rules that produced a word-processing document.
The extension alone does not create that structure. A converter must first render or interpret the source, then prepare page imagery and encode it in DjVu's chunk-based format. A single page is a FORM:DJVU container; a multi-page document uses FORM:DJVM. The first bytes identify the family as AT&T, not as PDF, JPEG, TIFF, or Office Open XML. This matters when choosing input: if a source already contains reflowable paragraphs, tracked edits, hyperlinks, and vector drawings, turning it into page imagery can remove the advantages of its original format. If the source is already a scan, the conversion can instead use DjVu's intended strengths.
PDF, TIFF, image, and office input take different routes
A scanned PDF is usually the strongest candidate. Its pages are already images of paper, so the conversion can segment each page into visual roles rather than trying to dismantle an editable document. A TIFF scan is similarly suitable, especially when it is a black-and-white page image. DjVuLibre includes cjb2 for turning bitonal PBM or TIFF input into JB2-coded DjVu data and c44 for color PPM or JPEG input using the IW44 encoder. Its csepdjvu encoder takes pre-separated foreground and background data and writes a DjVu document. These are concrete, different routes, not one universal algorithm that treats every file as identical.
A born-digital PDF, DOCX, ODT, presentation, or HTML page takes a less natural route. It has to be rendered into pixels first, so vector text can become an image and responsive or editable structure can become fixed layout. The result may look accurate at its output resolution, but it is no longer a document whose text reflows, whose revision marks work, or whose embedded fonts remain live. A photo can be encoded as DjVu, but a photographic page without a sharp text mask does not give the format much opportunity to show its special efficiency. A plain TXT file is the least sensible source: it has no page design or raster data to preserve and will be larger and less editable after being turned into page imagery.
DjVuLibre's csepdjvu documentation gives 300 dpi as its default resolution and accepts meaningful resolution values from 25 to 6000 dpi. That number is written into the output page so a decoder knows how to scale the image for display; it does not manufacture 300 dpi detail if the source was a low-resolution screenshot. It is a common conversion mistake to select a very high output number and assume the document gained readable detail. Enlarging a 100 dpi page only creates more pixels that describe the same blurred edge. Start from a scan with enough real detail for the smallest type, then choose an output resolution that keeps that detail legible at the intended viewing or print size.
DjVu's page model explains why the number is not the whole story. A typical compound page may keep its text mask at high resolution while storing background and foreground color at lower resolution. The mask is commonly encoded with JB2 and BZZ compression in an Sjbz chunk; the color layers use IW44 in BG44 and FG44. This split can make ordinary printed letters sharp without storing every square of blank paper at the same detail. In csepdjvu, the background quality setting controls the IW44 background encoding. Lowering it reduces size but can damage photographs, paper texture, colored diagrams, or fine shaded marks long before a simple page preview makes the problem obvious.
Reasons the output earns its specialized destination
- Gain - efficient scanned text: a high-resolution bitonal mask can preserve letters while lower-resolution image layers hold paper and color information.
- Gain - compact repeated page marks: the JB2 mask method can exploit repeated glyph-like shapes on printed material instead of storing each one as unrelated pixels.
- Gain - a bundled multi-page result:
csepdjvuwrites multiple supplied pages as one bundled DjVu document rather than requiring one output file per page. - Gain - optional text and navigation: hidden text, thumbnails, and an outline can be present where the conversion path deliberately creates or transfers them.
- Loss - ordinary sharing support: DjVu needs a compatible viewer; it is not opened natively by the same broad set of browsers and devices as PDF.
- Loss - editable source behavior: converting office files or live HTML to DjVu freezes a rendered page and cannot retain every interactive or revision feature.
A good destination choice is based on the next task, not on a vague promise of smaller files. DjVu fits storage and delivery of high-quality scans when the recipient has a suitable reader. PDF fits routine handoff and browser viewing. TIFF may remain appropriate for a lossless master image, and the original DOCX, ODT, or HTML should stay authoritative when ongoing editing is required. Keeping the original plus a derived DjVu is more reliable than asking a compact scan format to act as every kind of document at once.
Reader support and the destination's practical limit
DjVuLibre is the open-source reference implementation and provides the DjView viewer, decoders, simple encoders, and utilities. DjView4 has builds for Unix-like systems, Windows, and macOS. Other practical readers include WinDjView and SumatraPDF on Windows, plus Okular on Linux. A dedicated reader should be used to inspect the result before it is sent anywhere. Modern browsers are dependable PDF viewers but not dependable native DjVu viewers, and ordinary word processors are not a sound test for a DjVu archive file. A file that opens on the encoder's computer may still be unusable for a recipient who has no viewer installed.
Compatibility also means more than displaying page pixels. A viewer can show the image while not exposing the optional text layer to a print driver. A viewer can ignore an outline that another application understands. Open the output, move through every page, test a search term, copy a short sentence into a text editor, and open the outline panel if the input had a table of contents. If common-reader access is the actual goal, make a reviewed PDF alongside the DjVu rather than relying on the recipient to find an old plug-in or a random download.
Why searchable input can arrive as an unsearchable DjVu
DjVu has an optional hidden text layer, usually generated by OCR, that connects page locations to Unicode text for searching and copy-paste. The presence of selectable text in a PDF does not guarantee that a PDF-to-DjVu route will place equivalent text in the result. DjVuLibre's gsdjvu project documented a specific limitation: Ghostscript can pass drawing operations to its drivers but does not decode a PDF's hidden text overlay, so that overlay was not available for gsdjvu to store. A 2015 issue records this as a wont-fix limitation of that path. The visible page can therefore survive while search silently disappears.
The fix is not to rename the output or to assume OCR was preserved. First, test the finished DjVu with search and copy-paste. If it has no text layer, extract or create text separately with OCR and use a tool that can add it to the DjVu, or keep a searchable PDF beside the compact DjVu. If text is present but copied words are wrong, the source overlay or new OCR may be inaccurate, especially in multi-column pages, old type, or mixed-language scans. Compare copied passages against the visible scan. For exact quotation and accessible text, a manual correction pass is still required; compression cannot validate OCR.
Source routes into DjVu compared before the conversion
| Input type | What DjVu receives | Mandatory review |
|---|---|---|
| Scanned PDF | Rendered page imagery, often a strong fit | Text-layer transfer, page order, and fine print |
| TIFF or bitonal scan | High-detail page image; JB2 route suits black text | Real source resolution and clean scan edges |
| Color JPEG or photo scan | Color imagery; IW44 can encode it | Photograph artifacts and readable small type |
| DOCX or ODT | Rendered fixed pages, not editable document rules | Fonts, page breaks, tables, and lost revisions |
| HTML | One renderer's interpretation of CSS layout | Fonts, responsive width, scripts, and print CSS |
| TXT | Rasterized words with no formatting benefit | Whether conversion is useful at all |
Questions that settle whether DjVu is the right endpoint
Can a DOCX become a smaller, editable DjVu document?
No. It can become a DjVu rendering of pages, but the editable WordprocessingML structure, revisions, and many application features do not become native DjVu behavior.
Does 600 dpi output make a 150 dpi scan sharper?
No. The resolution entry tells the viewer how to scale the page. It cannot invent edge detail that the original scanner never captured.
Why did search stop working after converting a searchable PDF?
Some PDF-to-DjVu routes render the page but do not transfer the PDF's hidden text overlay. Test the actual DjVu text layer and add or regenerate OCR if search is required.
Should a DjVu file replace the original scan or document?
No. Keep the source. A DjVu copy is a derived, often lossy delivery or storage format whose special compression and reader requirements serve a different job.