GitHub Repo to Text: The Complete Guide to Converting Repositories for LLMs (2026)

Converting a GitHub repo to text means flattening every relevant source file into one plain-text file that an LLM can read in a single prompt. You can do it three ways: a browser tool like Repo2Txt, a CLI tool like Repomix or gitingest, or a short script. This guide covers all three, with real token counts.

I've pasted repos into Claude and ChatGPT hundreds of times while building Repo2Txt, and the difference between a clean dump and a lazy one is usually 5x in token count. That's the difference between fitting your whole codebase in context and getting a truncated, confused answer.

Here's everything that actually matters.

Why convert a GitHub repo to text at all?

LLMs can't browse your repo the way you do. They see a continuous stream of text and reason best when the relevant code is all in context at once — file structure, imports, and implementations side by side.

Context windows have grown enough to make this practical. Claude's current models accept 200,000 tokens by default (roughly 150,000 words, per Anthropic's documentation), and both GPT-4.1 and Gemini 2.5 Pro accept up to 1 million tokens according to OpenAI's and Google's model documentation. A mid-size codebase fits comfortably — if you strip the junk first.

The rough conversion rule from OpenAI's tokenizer docs: 1 token ≈ 4 characters of English or code. A 300 KB repo of actual source lands around 75,000 tokens. A repo dumped carelessly with lockfiles and build artifacts can blow past 500,000.

That's the whole game: get the signal in, keep the noise out.

How to convert a GitHub repo to a text file (step by step)

The fastest method is a browser-based GitHub repo-to-text converter. Here's the exact flow I use with Repo2Txt:

1. Open repo2txt.com and paste the repository URL (e.g. https://github.com/expressjs/express). Public repos need nothing else; private repos need a fine-grained personal access token with read-only contents permission.

2. Fetch the file tree. You get a checkbox tree of every file and directory before anything is converted. Nothing is dumped blindly.

3. Deselect the noise. Uncheck package-lock.json, dist/, .svg and image assets, test fixtures, and anything generated. This step matters more than any other — details below.

4. Check the token count. Repo2Txt shows a live token estimate as you select and deselect files, so you know whether you're under your model's context limit before you paste.

5. Generate and copy. You get one text file: a directory tree at the top, then each file's contents under a clear path header, so the LLM knows which file it's reading.

Total time on a repo I know: under a minute. On an unfamiliar repo, a couple of minutes of deciding what to exclude.

Working from a folder on disk instead of GitHub? The same flow works with the local directory to text converter, which processes everything in your browser — files never leave your machine. GitLab users get the same treatment at the GitLab repo to text converter.

A worked example with real token counts

I ran a client's Next.js SaaS starter through this — 214 files, TypeScript, Tailwind, Prisma. Here's what selective exclusion did:

One lockfile was 98,000 tokens — a quarter of your Claude context spent on dependency hashes the model will never use. The final 71,000-token dump fit into a single Claude prompt with 129,000 tokens of headroom for the actual conversation.

My default exclusion list, in rough order of token savings:

• package-lock.json, yarn.lock, pnpm-lock.yaml, Cargo.lock, poetry.lock

• node_modules/ (rarely in the repo itself, always in local folders)

• dist/, build/, .next/, out/, coverage reports

• Binary and media assets: images, fonts, PDFs

• Generated code: migrations, protobuf output, GraphQL codegen

• Large data fixtures and test snapshots

Keep package.json, tsconfig.json, and your CI config — small files that tell the model a lot about how the project fits together.

What are the best tools to convert a GitHub repository to a single text file?

I built one of these tools, so take my ranking with that context — but the honest answer is that the right tool depends on where you work.

Genuine trade-offs: Repomix is stronger than Repo2Txt for automation — if you want repo-to-text as a build step with a committed config file, use Repomix. gitingest's URL trick is the lowest-friction option for public repos when default exclusions are good enough. Repo2Txt wins when you want to see and hand-pick files before converting, when the code is private, and you don't want it touching a server (local mode runs entirely in-browser), or when you just don't want to install anything.

If you prefer the CLI route:

# Repomix
npx repomix --ignore "**/*.lock,dist/**"

# gitingest CLI
pip install gitingest
gitingest https://github.com/expressjs/express

And the minimal DIY version, good enough for small repos:

git clone --depth 1 https://github.com/user/repo && cd repo
find . -type f -name "*.ts" -not -path "./node_modules/*" \
  -exec sh -c 'echo "=== $1 ==="; cat "$1"' _ {} \; > repo.txt

The DIY script breaks down once you need per-file-type rules, token counting, or binary detection. That's the point where a purpose-built tool stops being optional.

How should you format a GitHub repo to text for LLM prompts?

Format affects answer quality more than people expect. Three things I've found consistently matter when preparing a GitHub repo to text for LLM use:

Include the directory tree first. A tree at the top level lets the model reason about architecture before reading a single line of code. When I ask "where should the rate limiter live?", answers that reference the tree are consistently better structured than those from a flat concatenation.

Use unambiguous file delimiters. Every file needs a header like === src/lib/auth.ts === or an XML-style tag. Without them, models blur adjacent files together and hallucinate imports that don't exist.

Put your instructions after the code, not before. Long-context models place heavy weight on the end of the prompt. Paste the repo dump first, then ask your question. When I invert this on large dumps, instruction-following degrades noticeably.

Repo2Txt's output ships the tree plus delimited files by default, so you only handle the last point yourself.

When is converting the whole repo the wrong move?

Honest limitation: beyond roughly 150,000 tokens of code, retrieval quality within a single prompt degrades, even in models that technically accept 1M tokens. Needle-in-haystack benchmarks look great; multi-hop reasoning across a giant dump is shakier.

For big monorepos, convert the slice you're working on — one package or service plus shared types — instead of everything. The checkbox-tree approach makes this natural: fetch once, select the subtree, regenerate. For repeated deep work on the same large codebase, an editor-integrated tool with retrieval (Cursor, Claude Code) beats pasting dumps. Repo-to-text shines for portable, one-shot, full-context jobs: code review, onboarding docs, migration planning, security passes, or asking a model to explain an unfamiliar codebase.

FAQ

How do I convert a GitHub repo to a text file for free?

Paste the repo URL into a free browser converter like Repo2Txt, deselect lockfiles and build artifacts in the file tree, and download or copy the generated text file. No install, no signup, and no server upload in local mode. CLI alternatives like Repomix and gitingest are also free and open source.

Can I get a GitHub repo to text online for free without installing anything?

Yes. Browser-based tools do the entire conversion client-side or via the GitHub API, so nothing gets installed. Repo2Txt works with public repos out of the box and private repos via a read-only personal access token. This is the practical route on locked-down work machines where you can't install npm or pip packages.

How many tokens is a typical GitHub repository?

A small library runs 20,000–60,000 tokens; a mid-size app repo runs 80,000–400,000, depending on lockfiles and assets. Using the ~4 characters-per-token rule, estimate tokens as file size in KB × 250. A live token counter is more reliable, since code tokenizes differently than prose.

Should I include package-lock.json when converting a repo for an LLM?

No. Lockfiles are the single biggest token waste in most conversions — the one in my worked example cost 98,000 tokens alone — and they contain nothing an LLM needs. Keep package.json instead: it's tiny and carries the dependency information that actually informs the model's answers.

Is it safe to convert a private GitHub repository to text?

Depends on the tool's architecture. CLI tools run locally, so code never leaves your machine. For browser tools, check whether processing is client-side: Repo2Txt's local mode reads folders directly in your browser without uploading to a server, and GitHub mode calls the GitHub API from your browser using your own token.

What's the difference between Repo2Txt and Repomix?

Repo2Txt is a browser tool built around visual file selection — you see the tree, check what you want, and watch the token count update before converting. Repomix is a CLI built for repeatability — exclusions live in a config file and run identically every time, making it a better fit for scripts and CI.