repo2txt: turning a repository into one prompt-ready text file
Web-based tool converts GitHub repository contents into a single formatted text file
At a glance
- What is it?
- repo2txt is a browser-based TypeScript tool that flattens a GitHub, GitLab, Azure DevOps, local or zipped codebase into a single formatted text file with a token count. The design is genuinely local-first, but the README's own feature list is the best guide to where it stops being the right tool.
- Who is it for?
- Adopt repo2txt if you paste repository context into a chat model by hand and want the file selection, ignore patterns and token count handled in one browser tab, especially for private repos where a token in sessionStorage is acceptable. Skip it if your context is a monorepo whose text exceeds the model window, or if you need a reproducible artefact for a CI job, because the output is produced interactively rather than by a command you can commit.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 42 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The paste-a-repo problem repo2txt targets
Handing a language model enough context to reason about a codebase usually means assembling that context manually. You open a file tree, decide which files matter, copy them one at a time, paste them into a prompt, and lose track of how large the result has become. For a small library this takes a few minutes. For anything with a src directory and a test directory, it takes longer than the question you wanted to ask.
repo2txt addresses exactly that gap. The README frames it as a tool to "Convert repositories to plain text for LLM prompts", and the intended user is a developer preparing context for a chat model rather than someone building an automated pipeline. The output is a formatted text file you copy to the clipboard or download as .txt, which tells you the unit of work is a single interactive session. The topics attached to the repository (ai, anthropic, chatgpt, llm, developer-tools) point the same way.
The secondary audience is anyone who wants a readable dump of a project tree without cloning it. The GitHub provider accepts a URL and returns file contents, so a reviewer can inspect a repository's structure and selected sources without a local checkout.
Five providers, one filtering pipeline
The architecture visible in the README is a provider model. GitHub, Local Files, Zip Upload, GitLab and Azure DevOps each supply file trees and file contents, and everything downstream (extension filters, .gitignore patterns, custom ignore patterns, directory selection, the file tree preview, token counting, export) operates on that common shape. The README labels GitLab and Azure DevOps as Beta, which is the honest signal that those two paths have had less exposure than the GitHub one.
Two implementation details are worth naming because they shape behaviour. Tokenization runs in Web Workers, so counting tokens does not block the interface while a large tree loads. Virtual scrolling via TanStack Virtual is what allows the file tree to present repositories the README describes as having 10,000+ files without rendering every row. Code splitting means each provider is lazy-loaded, which is why the main chunk is quoted at roughly 330KB gzipped rather than something larger.
The privacy claim is structural, not a policy statement. Because the tool is browser-based, code selected from a local directory or a zip never leaves the machine: there is no server component in the described flow. GitHub contents are fetched from GitHub's API directly by the browser, and the README states that GitHub tokens are stored in sessionStorage only. That is a narrower lifetime than localStorage, though it still means the token lives in a page context you should treat as sensitive.
Running it locally and what the URL parser accepts
The online deployment at abinthomas.in/repo2txt requires no installation. To run it yourself, the README gives these commands:
git clone https://github.com/abinthomasonline/repo2txt.git cd repo2txt npm install npm run dev
The dev server serves at http://localhost:5173/repo2txt/, and the path suffix matters: the app is built for a subpath, so opening the bare root will not work. For a production bundle, npm run build writes to ./dist.
Repository input is a URL rather than an API call. The README lists the accepted forms: https://github.com/owner/repo for the default branch, /tree/branch-name for a branch, and /tree/branch-name/path/to/folder to scope the load to a subdirectory. Branch names containing slashes are supported, which is the case the README calls out explicitly because naive splitting on the tree segment breaks it.
Adding a personal access token is optional but changes the rate limit from 60 to 5000 requests per hour, per the README, and is required for private repositories. That 60-request ceiling is the practical constraint on anonymous use: a repository with many files will exhaust it quickly, and the failure will look like a partial load rather than a clear error unless the interface reports it. The README does not describe the error surface for rate limiting, so verify it yourself if you plan to browse large public repositories without a token.
Token counting is a budget check, not a guarantee
The token counter uses gpt-tokenizer and reports per-file token and line counts alongside a running total. This is the feature that distinguishes repo2txt from a shell script that concatenates files: you can see, before generating output, whether the selection fits the model you intend to use.
The limitation is that a GPT tokenizer is not every tokenizer. If you are targeting Claude, Gemini, or a locally hosted model, the count is an approximation whose error depends on the content. Code with heavy punctuation and long identifiers tends to diverge more than prose. The README does not claim cross-model accuracy, and it should not be read as doing so.
A second constraint is that the tool produces one flat text file. Nothing in the described workflow chunks the output, summarises it, or selects files by relevance. The filtering is explicit and manual: extension toggles, .gitignore patterns, custom patterns, directory selection. For a repository whose full text exceeds the context window, repo2txt tells you the number but leaves the reduction to you. That is a reasonable division of labour for a browser tool, and it is also the point at which the tool stops helping.
Where repo2txt is the wrong choice
The clearest failure mode is scale without selection. If you load a repository with 10,000+ files and select everything, the output will exceed any current context window, and the token counter will simply report a large number. Virtual scrolling keeps the interface responsive; it does not make the payload fit.
A second case is reproducibility. There is no documented non-interactive mode. The README describes a web UI and an npm dev/build workflow, not a CLI that takes a repository URL and writes a file. If you want the same context bundle generated on every commit, or attached to a pull request, repo2txt is not the mechanism, because the selection lives in a browser session rather than in a committed configuration file.
Third, the Beta providers. GitLab and Azure DevOps are labelled Beta in the README, and the release list retrieved for this review is empty, so there is no changelog trail describing how those integrations have behaved. If your organisation runs on GitLab, treat that path as unproven and test it against a small repository before depending on it.
Finally, the licence. The README states MIT and links to LICENSE, but the repository metadata retrieved for this review does not carry a licence identifier. The README badge and the metadata disagree, which is worth resolving by reading the LICENSE file in the repository before you redistribute anything.
How it differs from repomix and gitingest
The closest alternatives in this space are repomix and gitingest, both of which also pack a repository into a single text representation for model input. The difference is where the work happens. repomix and gitingest are command-line tools: you install them, run them against a path or a remote repository, and they write a file. That makes them scriptable and reproducible, and it makes them the natural choice for CI.
repo2txt inverts that. It runs in the browser, which means no installation, no Node version to manage, and no shell access needed. It also means the selection step is visual and interactive, with a file tree, extension toggles and a live token count, which is easier to reason about when you are exploring an unfamiliar codebase. The cost is that the result is not a committed artefact. You cannot diff two runs of repo2txt the way you can diff two repomix outputs.
There is also a privacy distinction worth stating precisely. All three keep local files local, but repo2txt fetches remote repository contents from the browser using your token, while a CLI tool typically fetches from your machine. In both cases the code goes from GitHub to your device, not to a third-party server, provided you are using the official deployment.
Maintenance, upgrades and what to verify
The stack is current and opinionated: React 19, Vite 5, Tailwind CSS 3, Zustand for state, JSZip for archive handling, gpt-tokenizer for counting, TanStack Virtual for the tree, and Vitest with Playwright for tests. Upgrading means tracking those dependencies, and the React 19 and Vite 5 pair in particular will move as those projects release. The repository has no published releases, so there is no versioned upgrade path to follow; you are tracking the master branch.
Testing is split between unit and end-to-end, with npm run test:unit and npm run test:e2e documented in the contribution guide. The README claims a 100% E2E test pass rate and Lighthouse scores of 95 or above, along with a first load under two seconds on 3G and support for Chrome 90+, Firefox 88+, Safari 14+ and Edge 90+. Those are the project's own figures, and the browser floor matters if you are on an older enterprise image.
Before adopting, check four things against the live tool rather than the README. Confirm the GitLab and Azure DevOps providers still carry the Beta label. Confirm that nested .gitignore files are handled the way your repository expects, since the README describes gitignore support without specifying depth. Confirm the token count against your actual target model on a sample of your code. And read the LICENSE file, because the README's MIT badge and the repository metadata do not currently agree. The project is also documented for agents: AGENT.md is described as design documentation for LLM agents, which is a useful second source if the README is too thin on a particular behaviour.
Editorial conclusion
Adopt repo2txt if you paste repository context into a chat model by hand and want the file selection, ignore patterns and token count handled in one browser tab, especially for private repos where a token in sessionStorage is acceptable. Skip it if your context is a monorepo whose text exceeds the model window, or if you need a reproducible artefact for a CI job, because the output is produced interactively rather than by a command you can commit. Before relying on it, verify three things on the live site: whether the GitLab and Azure DevOps providers are still marked Beta, whether .gitignore handling matches your repository's nested ignore files, and whether the token counter's model matches the one you are actually sending to.
Community notes