Codebase to Text: How to Turn Any Project Into One LLM-Ready File

Converting a codebase to text means combining your project's source files into a single plain-text file that an LLM can read in one prompt. The format that works best puts a directory tree first, then each file's contents under a clear path header. You can produce this with a browser tool like Repo2Txt, a CLI, or a short script.

I've fed a lot of projects to Claude and ChatGPT while building Repo2Txt, and the mistake I see most often is dumping everything and hoping the model sorts it out. It won't. A well-structured codebase in a text file gets you sharper answers and uses a fraction of the tokens.

Here's how to do it right.

What does "codebase to text" actually mean?

 It means flattening a multi-file project into one continuous text file, so the model can hold it all in context at once. Instead of the model browsing files the way you do in an IDE, it reads a single stream: the folder structure, then every file's contents in sequence.

Why bother? Because LLMs reason best when the relevant code sits in context together, imports next to the functions that use them, config next to the code it configures. The current models make this practical. Claude's models accept 200,000 tokens by default (about 150,000 words, per Anthropic's documentation), and Gemini 2.5 Pro accepts up to 1 million tokens according to Google's model documentation. Most projects fit if you're deliberate about what goes in.

What should you include when you convert a codebase to a text file?

This is the decision that determines whether your file is useful or bloated. The rule I follow: include what explains the project, exclude what a machine generated.

Include:

• Source files (.ts, .py, .go, .rs, whatever you actually write)

• Config that shapes behavior: package.json, tsconfig.json, Dockerfile, CI workflows

• Schema and type definitions

• A README, if it explains the architecture

Exclude:

• Lockfiles: package-lock.json, yarn.lock, poetry.lock : huge and useless to a model

• Build output: dist/, build/, .next/, coverage reports

• node_modules/ and other vendor dependencies

• Binary assets: images, fonts, PDFs

• Generated code: migrations, protobuf output, codegen

The reasoning behind excluding lockfiles: they're pure dependency hashes. A single package-lock.json I measured that the total came to 98,000 tokens; nearly half a Claude context window was spent on data the model will never reference. Keep package.json instead; it's tiny and tells the model everything it needs about dependencies.

The output format that helps LLMs parse code

Format matters more than people expect. After a lot of trial and error, the structure that consistently works is a directory tree first, then delimited file contents. Here's the exact shape Repo2Txt produces:

project-root/
├── src/
│   ├── index.ts
│   ├── auth.ts
│   └── utils/
│       └── tokens.ts
├── package.json
└── tsconfig.json

=== src/index.ts ===
import { authenticate } from './auth';
// ... file contents ...

=== src/auth.ts ===
import { countTokens } from './utils/tokens';
// ... file contents ...

=== package.json ===
{
  "name": "example",
  "dependencies": { ... }
}

Two things make this work. The tree up top lets the model reason about architecture before reading a single line. When I ask "where should rate limiting live?", answers that reference the tree are consistently better organized. And the === path === delimiters stop the model from blurring adjacent files together and hallucinating imports that don't exist.

One more habit: put your actual question after the code, not before. Long-context models weight the end of the prompt heavily, so paste the dump first, then ask.

How to convert your entire codebase to a text file, step by step

Here's the fastest path using a browser-based tool. This works whether your code is on GitHub or sitting in a folder on your machine:

1. Open the tool. For a GitHub project, paste the repo URL at repo2txt.com. For a folder on disk, use the local codebase to text converter, which processes everything in your browser; files never leave your machine.

2. Load the file tree. You get a checkbox tree of every file before anything is combined.

3. Deselect the noise. Uncheck lockfiles, dist/, image assets, and generated code. This one step is usually a 3–5x reduction in the token.

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

5. Generate and copy. You get one file: tree first, then delimited file contents, ready to paste into ChatGPT or Claude.

The whole thing takes a minute or two once you know what to cut.

Codebase to text: tools compared

I built one of these, so weigh my ranking accordingly, but the honest trade-offs are real.

Where each wins: Repomix beats Repo2Txt if you want codebase-to-text as a committed build step with a config file. Git is the lowest-friction for public repos. Repo2Txt is the pick when you want to hand-select files visually, when the code is private, and you don't want it hitting a server, or when you can't install anything on a locked-down work machine.

If you'd rather script it, the minimal version for a small project:

find . -type f -name "*.py" -not -path "./venv/*" \
  -exec sh -c 'echo "=== $1 ==="; cat "$1"' _ {} \; > codebase.txt

That breaks down fast once you need per-filetype rules, token counting, or binary detection, which is when a real tool earns its keep.

A real before/after token comparison

I ran a Python FastAPI project through this: 168 files, SQLAlchemy models, Alembic migrations, and a test suite. Selective exclusion did the heavy lifting:

The lockfile alone was 71,000 tokens. The final 64,000-token file was split into a single Claude prompt, with room to spare for the actual conversation, whereas the original 244,000 wouldn't have fit in a default 200K context at all.

When is turning your whole codebase to text the wrong move?

Honest limitation: beyond roughly 150,000 tokens in a single prompt, retrieval and multi-hop reasoning degrade, even in models that technically support a million tokens. The benchmarks that look great are simple lookups; reasoning across a giant dump is shakier.

For large monorepos, convert only the slice you're working on, one service plus shared types, instead of everything. And for repeated deep work on the same big codebase, an editor-integrated tool with retrieval (Cursor, Claude Code) beats pasting files. Codebase-to-text shines for portable, one-shot, full-context jobs: code review, onboarding, migration planning, or asking a model to explain an unfamiliar project.

FAQ

How do I give an LLM my whole codebase?

Flatten your project into a single text file with a directory tree followed by each file's contents, then paste it into the model. Use a browser tool like Repo2Txt or a CLI like Repomix to generate the file, and deselect lockfiles and build artifacts first to stay within the model's context window.

How do I convert an entire codebase to a text file for free?

Paste your repo URL or select a local folder in a free tool like Repo2Txt, uncheck generated files and lockfiles in the file tree, then copy or download the result. No signup or installation is required, and local mode processes files in your browser without uploading them to a server. Repomix and gitingest are free open-source CLI alternatives.

What's the best format for a codebase to a single text file for ChatGPT?

Put a directory tree at the top, then each file's contents under a clear path delimiter like === src/auth.ts ===. The tree lets ChatGPT reason about structure before reading code, and the delimiters stop it from merging files or inventing imports. Paste your actual question after the code, since models weigh the end of a long prompt most heavily.

Is there a project to txt converter online that doesn't upload my code?

Yes. Repo2Txt's local mode reads folders directly in your browser using the File System Access API, so nothing is uploaded to a server. For GitHub repos, it calls the GitHub API from your browser with your own token. CLI tools like Repomix also run entirely on your machine, which is the safest option for private or proprietary code.

How many tokens will my codebase be?

A small project runs 20,000–80,000 tokens; a mid-size app runs 80,000–250,000, depending on lockfiles and assets. Using the ~4-characters-per-token rule from OpenAI's tokenizer docs, estimate tokens as total file size in KB × 250. A live token counter is more accurate, since code tokenizes differently than prose.

Should I include tests when converting my codebase for an LLM?

It depends on the task. Include tests when you want the model to understand expected behavior, or write more tests. Exclude large fixture files and snapshots; they're often the biggest token sink after lockfiles, as the 33,000-token fixture folder in my worked example showed. Keep unit tests concise; drop generated data.