GitHub Repo to Text: Turn a Whole Repository Into One File an LLM Can Read
Paste a GitHub URL above and you get the repository's file tree in a checkbox list. Tick what matters, generate, and you have a single text file: the directory structure at the top, then each selected file underneath, separated by a header with its path. That's the format that works with ChatGPT, Claude, Gemini, DeepSeek, or anything else you paste into — the model sees the shape of the project and the code at the same time, so it can reason about how the pieces fit together instead of guessing from one file in isolation.
Nothing to clone, nothing to install, no sign-up, and it's free. The repo is read through the GitHub API straight from your browser, so you don't need the project on your machine at all — which is the point when you're looking at someone else's code, a dependency you're evaluating, or a repo you've just been given access to.
Paste the URL, Including the Branch or Tag
The plain https://github.com/owner/repo form works and gives you the default branch. But
the URL carries more than that, and it's worth using. Copy the address bar while you're browsing
GitHub and whatever you're looking at comes across:
- A branch —
/tree/developor a feature branch, so you can convert the work in progress rather than what's on main. - A tag or release —
/tree/v2.1.0. Useful when you're asking about the version you actually ship, or diffing two releases in conversation by converting each one. - A subdirectory —
/tree/main/packages/api. This is the one that saves you in a monorepo. Start at the package you care about and the tree you get back is already scoped, rather than ten thousand files you then have to untick.
If the branch or path doesn't exist you'll get told which part didn't resolve, which is usually a typo in a branch name or a repo that's private to the token you're using.
Private Repositories, and Where Your Token Goes
Private repos work with a GitHub personal access token. Generate one in your GitHub developer settings with read access to the repositories you need — a fine-grained token scoped to a single repo is enough, and it's the option worth taking. Paste it into the token field and the tree loads the same way a public one does.
The token is kept in your browser's localStorage so you don't retype it every visit, and
it goes to exactly one place: api.github.com, in the request headers, from your own
machine. There's no account here to attach it to and no backend of ours in the path. Clear the field
and it's removed from storage. On a shared machine, clear it when you're done, and if you ever want
certainty, revoke the token in GitHub afterwards — that's a one-click action and it costs you
nothing.
A token also helps on public repos. Unauthenticated GitHub API requests are rate-limited fairly aggressively, so if you're converting a large repository, or several in a row, adding a token is the difference between it working and you waiting an hour.
What to Untick Before You Generate
This is the step that decides whether the output is useful. A repository contains a lot of files that are tracked for good reasons and are still worthless as model context. Go through the tree and drop:
- Vendored dependencies —
node_modules,vendor,third_party. Rare in a repo but devastating when present. It's other people's source code, and it will drown yours. - Build output —
dist,build,out,.next,target, coverage reports. Your own code again, transpiled or minified, so the model reads everything twice and learns nothing new the second time. - Lockfiles —
package-lock.json,yarn.lock,poetry.lock,Cargo.lock. Tens of thousands of tokens of hashes with almost no meaning in them. Keep the manifest instead;package.jsonorpyproject.tomlis what tells the model which stack you're on. - Generated code — protobuf and gRPC output, GraphQL codegen, OpenAPI clients, database migrations, snapshot tests. Machine-written, repetitive, and it pushes the model toward editing files that get regenerated anyway.
- Big data files — fixtures, seed dumps, sample CSVs, minified bundles committed years ago. One of these can eat a context window on its own.
Filtering by extension is the fast route when a repo is large: narrow to .ts and
.tsx, or .py, and you've cut most of the noise in one move. Then add back
the handful of config and documentation files that explain the project — the README, the main config,
the schema.
The Token Counter Is the Part That Matters
The generated output comes with a token count, calculated with the gpt-tokenizer library
rather than a characters-divided-by-four estimate. Check it before you paste. Knowing whether a dump
fits the context window you're about to use is the whole game — the alternative is pasting, waiting,
and reading a length error.
Use it to steer, not just to check. If the count is double what you have room for, go back to the tree and untick a directory rather than truncating the file at the end, because a dump cut off mid-project leaves the model with half an implementation and no idea it's missing. And bear in mind that a big context window isn't the same as a good one: a focused 8,000-token selection — the module, its tests, and the two files it imports — usually beats 200,000 tokens of everything. Send the whole repo when the question is architectural, and a slice when it's local.
When it's ready, copy the text to the clipboard, download it as a .txt, or grab the
selected files as a ZIP if you'd rather have them as files than as one merged document.
How to Use It
What People Actually Use It For
- Onboarding onto an unfamiliar codebase. New job, new team, or an open source project you want to contribute to. Convert it, paste it, and ask for the entry points, the core abstractions, and the three things that would surprise a new maintainer. You'll get oriented faster than by reading the README and clicking through files for a day.
- Reviewing a pull request with its surroundings. A diff shows what changed but not what it touches. Convert the branch, or just the affected package, and ask what else calls the function that changed and what assumptions the new code makes about it.
- Writing documentation that's actually true. READMEs rot because they're written once. Generate an architecture overview, module summaries, or the real list of environment variables from the code as it exists on main today.
- Generating tests. Include the module plus one existing test file as a style reference. The model matches your framework, your naming, and your fixtures instead of inventing a convention nobody on the team uses.
- Migration and refactor planning. Class components to hooks, JavaScript to TypeScript, one ORM to another. A model that can see every call site produces a real sequence of steps rather than a generic checklist.
- Audits and due diligence. Assessing a repository you're inheriting, acquiring, or considering as a dependency. A consolidated file makes it practical to ask where secrets are handled, what the error paths look like, and where the risky patterns live.
- RAG and embeddings. Path-delimited sections chunk cleanly, so the output drops into a vector store with very little preprocessing.
Frequently Asked Questions
How do I convert a GitHub repo to a text file?
Paste the repository URL above and the file tree appears as a checkbox list. Untick what the model does not need, generate, and you get one text file: directory structure at the top, then each selected file under a header with its path. Nothing to clone, nothing to install, free and no sign-up.
How do I convert a private GitHub repository?
Paste a personal access token alongside the URL. Create a fine-grained token scoped to just that one repository with read-only Contents permission and a short expiry — that is the least privilege the API will accept for this. The token is used to call GitHub from your browser and is not stored on our side.
How many tokens is my codebase, and will it fit?
The counter updates as you tick files, so you can see the number before you paste anything. As a rough guide, source code runs around 3 to 4 characters per token, so a 500 KB selection lands near 140,000 tokens. That fits a 200K context window and will not fit into a single chat message on most interfaces.
Which files should I exclude before feeding a repo to an LLM?
node_modules, vendor, and any dependency directory first — they are usually the overwhelming majority of the bytes and contribute nothing about your code. Then lockfiles, build output, minified bundles, test fixtures, and binary assets. On a typical JavaScript project that pass alone often removes over ninety percent of the tokens.
How does this compare to gitingest, repomix, or code2prompt?
Those are strong tools and the honest difference is workflow, not capability. They are command-line first, scriptable, and the right answer inside CI or a batch job. This runs in a browser tab with a checkbox tree, so you can see the repo, deselect what you do not want, and watch the token count move — better for the one-off case where you are still deciding what to include.
Is it safe to put my code through this?
Public repositories are read through the GitHub API from your browser, so the code goes from GitHub to you. For anything confidential the stronger option is the local folder converter, which never uploads at all. Either way, scan your selection for API keys and credentials before pasting it into a model — that is the step people skip.
Local Folders, GitLab, and Everything That Isn't Code
Not everything you want to convert lives on GitHub. The local folder to text converter takes a directory straight off your disk and combines it into one file without uploading anything — no network calls at all, which is what you want for client work, uncommitted branches, or a project that was never a git repo. For GitLab, the GitLab to text converter does the same job against public and private projects hosted on gitlab.com.
Code is usually only half the context, too. The spec is in a PDF, the schema in JSON, the legacy config in XML, the sample data in a CSV. Convert those alongside your repo with PDF to Markdown, JSON to Markdown, XML to Markdown, CSV to Markdown, or HTML to Markdown. If someone hands you an archive, ZIP to text pulls the readable content out of it, and File2Txt takes any of the thirteen supported formats if you'd rather not pick a page. For documentation that only exists on the web, Web2Txt scrapes a URL into clean Markdown, including JavaScript-rendered pages — pair a scraped API reference with your converted repo and a coding assistant can see both sides at once.
There's more depth on the blog: the complete guide to converting GitHub repositories for LLMs, turning a codebase into an LLM-ready file, feeding a whole repository into an AI, and the folder to text walkthrough for local directories.
Repo2Txt is built and maintained by v12hero, an independent developer building privacy-first native and web apps.