ZIP to Text: Turning an Archive Into a Single Searchable Corpus
There's a specific moment this tool was built for. You've got an archive — an export, a backup, a bundle someone sent — full of documents in half a dozen formats, and what you actually need isn't to read them. You need to search across all of them at once. Count how often a term appears. Feed the lot to an embedding model. Find the three files out of eighty that mention a particular clause.
Upload the ZIP, get back one flat body of plain text containing everything readable inside it. No headings, no pipe tables, no syntax characters — just prose you can grep, index, chunk, or paste. Free, no account, 50 MB cap on the archive, nothing stored once you've got your output.
One Archive In, One Corpus Out
The archive gets unpacked, the tree inside is walked, and every file with a supported extension is converted
with the same logic it would get as a standalone upload. Then it all comes back joined together as continuous
text. Folder paths from inside the archive are carried through, so you can still tell that something came
from exports/2023/ rather than drafts/ — but the output itself is flat, uniform,
and mechanically easy to process.
The efficiency argument makes itself. Forty documents converted individually is forty uploads and forty clipboard operations. As a single bulk file to text conversion, it's one. And because everything lands in one output, there's no reassembly step afterwards — no worrying about whether you pasted file 23 twice and skipped 24.
Why Flat Text Beats Markdown for Bulk Work
Markdown earns its keep when a human reads the output or when document structure carries meaning. For most things you'd do with a whole archive at once, neither applies, and the markup becomes overhead:
- Embeddings and RAG pipelines. Chunkers work on prose. Pipe tables and heading markers get split across chunk boundaries, dilute the semantic signal in each vector, and consume budget that should be going to actual content. Most ingestion code strips Markdown as its first step anyway — start without it.
- Search indexing. Whatever you're feeding, a tokeniser wants clean words. Syntax characters become noise the analyser has to discard.
- Keyword and frequency analysis. Term counts, co-occurrence, TF-IDF, simple regex sweeps — all cleaner against unadorned text, with no risk of a table delimiter registering as a token.
- Deduplication and diffing. Comparing two archive conversions to see what changed is far easier when formatting can't introduce spurious differences.
- Token efficiency. Across dozens of documents, structural markup adds up to a real fraction of your context window. Dropping it buys you room for more source material.
Flip to ZIP to Markdown when the opposite is true — when you need clear boundaries between documents, when tables and clause numbering matter, or when you're going to read the result yourself. The format toggle at the top switches over and brings your selected archive with it, so you can produce both from one upload and see which suits the job.
Know What's In the Archive Before You Upload
Supported formats convert wherever they sit in the tree: PDF, Word, PowerPoint, Excel, HTML, CSV, JSON, XML, EPUB, RTF, MSG, and images. Mixed archives are the standard case. If you want the specifics on how a particular type behaves once flattened, see PDF to text, Word to text, CSV to text, or MSG to text for Outlook messages.
Things that get skipped: video, audio, binaries, fonts, and anything outside the supported list. Two more cases worth knowing about before you're surprised by the output.
- Images aren't read inside an archive. On their own, image files get their text recognised and returned. Bundled into a ZIP they don't — the batch pass notes the file and moves on, so an archive of screenshots or scanned pages processes without error and gives you filenames rather than the words in the pictures. When the words are the point, extract those images and send them through image to text one at a time.
- Scanned PDFs have the same problem. A PDF that's really a photo of paper has no embedded text to extract. Test one by trying to select a sentence in a reader — if you can't, run text recognition before you zip.
- Nested archives. A ZIP containing other ZIPs is worth unpacking one level by hand before uploading.
Where a Flat Corpus Earns Its Keep
- Document review at volume. A disclosure bundle or a data room export where the first question is "which of these even mention the thing I care about" — not "read me this document".
- Building a knowledge base. Company handbooks, policies, and process docs, converted in one pass and fed into a retrieval system as the ground truth an assistant answers from.
- Support and ticket exports. Months of conversations flattened into text you can run theme analysis over, or ask a model to cluster into recurring complaints.
- Research corpora. A folder of papers, reports, and datasets turned into one body of text for cross-document analysis rather than one-at-a-time reading.
- Migration and content audits. Before moving a documentation set to a new platform, convert the whole archive and search for dead references, outdated product names, or duplicated pages.
- Workspace exports. Slack, Notion, and Takeout downloads are structurally messy and full of nested folders. Flattening them is what makes them tractable.
Size, Order, and Sensible Batching
The 50 MB limit applies to the uploaded archive, not to files individually. Text-heavy documents compress well, so a lot of them fit; media does not compress and will eat the whole allowance for nothing. Strip out video and large images before zipping.
If you're going to work through the corpus in sections, split by folder and zip each section separately — one archive per client, per quarter, per project. It keeps each output at a size you can actually paste, and it keeps related material together. The token counter under the output is the number to steer by: it tells you immediately whether a batch fits your model's context window or needs splitting, before you find out the hard way.
And if the archive is a source-code project rather than documents, use the local directory converter instead. It gives you a checkbox tree of the folder so you can exclude dependencies, build output, and lock files before conversion — control an archive upload can't offer. Code already on a host is easier still: the GitHub to text converter works straight from a URL.
Frequently Asked Questions
How do I convert a ZIP file to text?
Upload the archive above. It is unpacked, the tree inside is walked, and every file with a supported extension is converted and joined into one flat body of plain text. Free, no sign-up, 50 MB per archive, nothing stored. Folder paths from inside the archive are carried through so you can tell where each part came from.
What file types inside the archive get converted?
The same thirteen this site handles as standalone uploads — PDF, Word, PowerPoint, Excel, HTML, CSV, JSON, XML, images, EPUB, RTF, Outlook messages, and nested archives. Anything else in the ZIP is skipped rather than dumped as binary noise, so a bundle mixing documents with videos and executables still produces clean output.
Does it work on password-protected archives?
No. An encrypted ZIP has no readable entries until it is decrypted with the password, and there is nowhere to supply one. Extract it locally with the password first, re-zip without encryption, or point the local folder converter at the extracted directory instead.
My archive is bigger than 50 MB — what now?
Split it by folder and convert in passes, or skip the archive entirely: extract it on your machine and use the local folder converter, which has no upload step, walks the whole tree, and lets you tick exactly which files to include. For a large document dump that is the better route anyway.
Is this the right tool for a zipped code repository?
Not really. For source code, the GitHub converter and the local folder tool are built for the job — they show you the directory tree, let you deselect node_modules and lockfiles, and count tokens as you go. This page is aimed at archives of documents, where there is no tree to prune.
The Rest of the Toolkit
File2Txt takes any supported format from a single page if you don't want to pick one. There's a longer guide to getting files ready for LLMs if you want the reasoning behind all of this in one place.
Repo2Txt is built and maintained by v12hero, an independent developer building privacy-first native and web apps.