Air-Gapped Document Search: Semantic Search on an Offline Machine

October 14, 2026 · 7 min read

If your documents live on a machine that never touches the internet, or one you keep offline by policy, most modern search tools are off the table. Cloud drives, AI assistants and many "smart" search features assume a connection to a vendor's servers. On an isolated workstation, the default is usually filename search or exact-keyword matching, which fails when you remember what a document said but not the words it used.

This article explains what air-gapped document search actually requires, where built-in tools fall short, how meaning-based search can run with zero network dependency, and what to check before installing any search software on a high-security machine.

What air-gapped document search actually requires

Air-gapped document search requires every step of the pipeline to run on the isolated machine itself, with nothing sent out and nothing fetched in at query time.

That pipeline has more stages than people expect:

1. Text extraction from PDFs, Word files, spreadsheets, slides and email files.
2. OCR for scanned PDFs and images, since a scan is just a picture until it is converted to text.
3. Indexing, so searches are fast instead of re-reading every file each time.
4. Query processing, which for semantic search means turning your query into a vector using an embedding model.
5. Ranking and results, shown locally.

If any one of these stages calls out to a server (a cloud OCR API, a hosted embedding service, a remote model download on first run), the tool is not suitable for an air-gapped setup. The same applies to features that quietly sync an index or telemetry. For machines handling regulated or classified material, the useful test is simple: does it still work, fully, with the network physically disconnected?

Isolation also does not replace basic device protection. Guidance such as NIST SP 800-111 on storage encryption for end-user devices still applies, and a local search index is one more file on disk that should sit inside your encrypted volume.

Why built-in search falls short on an isolated machine

Built-in operating system search works offline, but it matches words and filenames rather than meaning, so it struggles when you cannot recall exact terms.

Windows Search relies on an index of files, properties and contents that you can configure, and Spotlight does similar work on a Mac. Both are reasonable for finding a known filename or a distinctive phrase. Neither will reliably find "the memo about delaying the supplier payment" if the memo actually says "defer remittance to vendor until Q3". Scanned documents add another gap: if the content was never converted to text, keyword search has nothing to match.

Cloud options solve the meaning problem but break the air gap by design, because the files or their contents are processed on someone else's servers.

For a deeper look at the difference between the two approaches, see semantic search vs keyword search.

How meaning-based search runs with zero network dependency

Meaning-based search runs offline by using a small embedding model stored on the machine, which converts both documents and queries into vectors that can be compared locally.

The technique comes from sentence embeddings: text is mapped to a list of numbers so that passages with similar meaning end up close together. Sentence-BERT (Reimers & Gurevych, 2019) showed how this makes comparing text by meaning practical with simple vector similarity. Nothing about this requires a server. Once the model file is on disk, indexing and searching are just local computation.

Modern embedding models can be small. Fossick, a desktop app for Windows and Mac that searches your local documents by meaning entirely offline, uses the open all-MiniLM-L6-v2 model: 384 dimensions, quantized, about 22 MB, bundled and run locally. There is no model download at query time and no hosted API.

It is worth being precise about what this is and is not:

• It is search. You type what you remember, and it returns the documents and passages that best match the meaning.
• It is not chat. There is no chatbot, no generative AI, no summaries, and no model writing answers. Results are your own files, ranked.

That distinction matters in high-security environments, because a retrieval tool that only points you to existing documents is far easier to reason about than a generative system producing new text.

Using Fossick on an offline or air-gapped machine

Fossick indexes, runs OCR, embeds and searches entirely on the device, and works with Wi-Fi off; the only part that touches the internet is licensing.

In practice, that means:

• Text extraction, OCR, embedding and search all run locally. Documents are never uploaded.
• Supported files include PDF, Word (.docx, .doc), Excel (.xlsx), PowerPoint (.pptx), OpenDocument text (.odt), plain text, Markdown, CSV, HTML, email (.eml, .msg), and images (PNG, JPG).
• Scanned PDFs and images are made searchable with on-device OCR, so paper records that were scanned into the system are not invisible to search.
• Re-indexing is incremental: only new or changed files are re-processed, which suits machines where files arrive in batches via approved transfer media.

Be deliberate about licensing. Because licensing and billing are the one internet-dependent piece, decide how that fits your isolation policy before deployment, for example handling it on an approved connected step before the machine is isolated, or confirming the arrangement with the vendor. Do not assume any tool's activation works the way your policy requires without checking.

You can evaluate it first: Fossick is free to try with no sign-up or card, limited to 1 folder and up to 200 files. The full app is a single one-time purchase, with details on the pricing page. The installer is available from the download page and can be moved to an isolated machine through your normal approved media process.

Performance on modest, isolated hardware

Local semantic search is fast enough on ordinary laptops, because the model is small and the index is compact.

Air-gapped machines are often older or deliberately minimal, so it helps to know what to expect. Measured on 2026-09-21 on an Apple M1 MacBook with 8 GB RAM, using the engine CLI and a 52-document folder of mixed Word, PDF (including scanned pages), Excel, CSV and Markdown files totalling 700 KB:

• First-time indexing: about 81 seconds from scratch, including model load and OCR.
• Re-checking an unchanged folder: about 7 seconds.
• Search speed: about 15-20 ms median per semantic search (10 queries, 3 runs).
• Index size on disk: about 1.9 MB.

These are measurements on one small folder, not a promise for every collection. OCR-heavy archives will take longer to index initially, because converting scanned pages to text is the slowest step. After that first pass, incremental re-indexing keeps the ongoing cost low.

A verification checklist for security-sensitive teams

The most reliable way to trust an offline search tool is to test its network behaviour yourself rather than relying on marketing claims, including ours.

A practical evaluation on a test machine:

1. Disconnect the network physically (cable out, Wi-Fi off) before indexing.
2. Index a representative folder that includes scans, spreadsheets and email files.
3. Run searches by meaning, using paraphrases rather than exact phrases, and confirm results come back.
4. Reconnect under monitoring with a firewall or outbound connection monitor, and note what, if anything, the app contacts and when.
5. Locate the index on disk and confirm it sits inside your encrypted storage and backup policy.
6. Document the licensing step so it is approved in your isolation procedure.

If you are comparing tools more broadly, the best desktop search app guide covers other criteria, and on-device AI search, explained goes further into how local models work. More about Fossick itself is on the homepage.