How Does OCR Resolution Affect RAG Index Size?
OCR resolution affects RAG index size indirectly through recognition yield, noise, layout output, and retained images rather than through DPI alone.
Scanning a family archive at 600 DPI produces four times as many pixels as 300 DPI for the same page dimensions, but a text-only vector index does not store those pixels. Its size depends on the characters, layout objects, chunks, metadata, and embeddings emitted after OCR. Higher resolution may recover more real text, while very poor images can generate noisy tokens that also enlarge the index without improving answers.
Pixel Count Expands Before Text Enters the Index
Doubling linear resolution quadruples image pixels, increasing decode, preprocessing, temporary storage, and OCR work. If the pipeline retains page images, crops, or thumbnails beside vectors, those assets may dominate storage; a text-only index mostly discards the raster after extraction.
Tesseract’s recognition-quality guidance notes that recognition generally benefits from images around 300 DPI and that rescaling can help lower-resolution inputs. This is a recognition-quality recommendation, not a rule that an embedding database stores 300-DPI pixels.
The storage boundary must therefore be explicit: source files, OCR derivatives, text chunks, vector payloads, and thumbnails are separate layers. Changing DPI can affect each layer differently even when the final number of documents is unchanged.
Recognition Yield Changes Token and Chunk Counts
A clearer scan can recover footnotes, small labels, table cells, and punctuation that lower resolution misses. More valid text increases tokens and may create additional chunks and vectors. Conversely, broken glyphs and repeated garbage can inflate tokens because tokenizers split corrupted strings inefficiently.
Research on low-resolution OCR evaluates recognition from ultra-low-resolution documents and explains why systems designed around 300-DPI text behave differently after downsampling and enlargement. The results demonstrate that resolution and character scale affect extracted content, not only visual file size.
Layout-aware OCR can add coordinates, reading order, confidence, and table structure. Those payloads may exceed the plain text itself, so the same recognized words can produce different index sizes depending on whether spatial evidence is retained for citation.
Higher DPI Stops Helping After Glyph Detail Saturates
Once character strokes are resolved well enough for the OCR model, more pixels may increase compute and derivative image size without adding text. Compression artifacts, blur, skew, handwriting, and incorrect language models can remain the limiting factors at high DPI.
OCRmyPDF’s OCR image optimization describes optimization stages that can recompress or transform page images after recognition. It illustrates why PDF size after OCR depends on image encoding and optimization policy, not simply on the scan resolution used at ingestion.
The failure boundary is assuming index growth proves better OCR. An index can grow because it recovered useful text, duplicated overlapping chunks, retained larger images, or produced noise; only ground-truth recognition and retrieval tests distinguish those causes.
FAQ About OCR Resolution and Index Storage
Is 600 DPI always better than 300 DPI for RAG?
No. Six hundred DPI can help tiny print or detailed forms, but it often adds processing and image storage after ordinary printed text is already resolved. Test character accuracy and retrieval rather than selecting the highest scanner setting by default.
Do embeddings become larger when the scan DPI increases?
The vector dimension usually stays fixed for a given embedding model. The index grows only if higher-resolution OCR produces more chunks, more metadata, additional region embeddings, or retained image derivatives. This effect should remain measurable under the intended home-server workload.
Can low-resolution OCR make an index larger?
Yes. Garbled character sequences can tokenize into many fragments and create noisy chunks. A smaller source image can therefore produce more text tokens than a clean scan while yielding worse retrieval and citations. The distinction matters when several pipeline stages share the same storage and memory budget.
Measure Storage by Pipeline Layer
Select pages with normal text, small print, tables, handwriting, and degraded scans. Process them at several effective resolutions while holding OCR model, language, chunking, embedding dimension, and retention policy constant, then record character accuracy, token count, chunk count, vector bytes, metadata bytes, derivatives, temporary peaks, and retrieval quality.
Use the reading-order checks in reading-order checks when tables or forms are present. Attribute every byte to source images, OCR output, chunks, vectors, or thumbnails so a larger directory is not misreported as vector-index growth.
Choose the lowest resolution that meets recognition and citation targets for each document class. Store high-resolution sources only where later reprocessing needs them, and remove noisy OCR or redundant derivatives before concluding that more pixels improve the knowledge base.
Recommended products
Tech & AI HUB
More to Read
Can a Local LLM Resume Generation After Its Process Restarts?
A mechanism-first explanation of llm generation resume, its shared-resource tradeoffs, three query-fanout FAQs, and a practical verification protocol.
Can a Home Server Run Embeddings and Video Transcoding on the Same Integrated GPU?
A mechanism-first explanation of shared igpu embeddings and transcoding, its shared-resource tradeoffs, three query-fanout FAQs, and a practical verification.
How Does Access-Token Lifetime Affect Security and Household Friction?
A mechanism-first explanation of access-token lifetime, its shared-resource tradeoffs, three query-fanout FAQs, and a practical verification protocol.
