GitLab Repo to Text: One File Your LLM Can Actually Read
Pasting code into a chat window one file at a time is a bad way to spend an afternoon. The model answers each question with a keyhole view of your project, you keep having to say "wait, here's the other file it imports", and by the time the context is complete the conversation has gone sideways. The fix is boring and effective: give it the whole relevant slice of the repository up front, in one block of text.
That's what this page does. It's the shortest path from a GitLab repository to LLM context: paste a
https://gitlab.com/... project URL, the tool reads the
repository tree through GitLab's API, and you get a checkbox tree of every file. Tick what matters,
untick what doesn't, hit generate. Out comes a directory map followed by the full contents of the files
you chose, with a token count so you know whether it fits. Copy it, download it as text, or grab the
selected files as a ZIP.
Paste the URL You're Already Looking At
There's no project ID to look up and no separate namespace field. Copy the URL out of your browser's
address bar and paste it in. Nested subgroups work — GitLab's habit of burying a project three or four
levels deep under company/platform/services/billing is handled, because the project path
gets URL-encoded before it reaches the API.
If the URL you copied includes a branch or tag, that ref is used. If it's just the bare project URL, the
project's default branch is resolved automatically, so you don't need to remember whether this particular
repo settled on main, master, or develop. The tree is fetched
recursively and paginated, which matters more than it sounds — plenty of GitLab monorepos run to
thousands of files, and a single unpaginated request would quietly give you a truncated project.
Private Projects, and Exactly Where Your Token Goes
Public projects need nothing. For a private one, add a GitLab personal access token and it's sent as the
PRIVATE-TOKEN header on requests to
GitLab's API.
Being cautious about pasting a token into a web tool is the correct instinct, so here is the plain version:
the token is stored in your browser's localStorage and used only to call
gitlab.com directly from your browser. It is not sent to any server of ours, because the
requests don't route through one.
Read-only scope is all it needs — read_api or read_repository. Don't hand it
write access it will never use, and set an expiry while you're in the token screen. It's also worth
adding a token even for public repos: unauthenticated calls to the GitLab API are rate limited, so if
you're pulling a large project or re-running the same conversion a few times, an authenticated request
is the difference between a smooth fetch and a wall of errors.
Self-Managed GitLab: The Honest Answer
This tool talks to gitlab.com and only gitlab.com. There's no field for a custom
instance URL, and pasting gitlab.yourcompany.internal won't work. If you're on a self-hosted
or self-managed instance, that's a straight no.
The good news is that the better answer for a self-managed instance was never an API call anyway. Clone the repo — you already have credentials — and point the local directory converter at the folder. It reads files through the browser's file APIs, so nothing is uploaded and nothing leaves your machine. For a private instance sitting behind a corporate firewall, that's the version your security team would have asked for regardless. Same checkbox tree, same output, same token count. It also takes a ZIP if you'd rather export an archive than clone.
What to Select, and What to Leave Out
Everything starts checked, which is the wrong selection for almost every real project. The instinct when you convert a GitLab repo to text is to take all of it; resist that. A useful repo dump is a curated one — the token budget you spend on generated noise is budget the model doesn't spend on your actual code. Untick these first:
- Vendored and installed dependencies —
node_modules,vendor,.venv, anything checked in from a package registry. The model already knows what Express looks like. - Lockfiles.
package-lock.json,yarn.lock,poetry.lock,Gemfile.lock. A lockfile can be tens of thousands of tokens of hashes and version pins that answer no question anyone ever asks. Keep the manifest, drop the lock. - Build output and minified assets —
dist,build,.next, compiled bundles, source maps. It's your own code, restated in a form nothing can reason about. - Snapshots and fixtures. Large test fixtures and snapshot files are repetitive by design. A couple of representative ones beat all four hundred.
- Migrations, mostly. A schema directory with six years of incremental migrations is worth including only when the question is about the migration history itself.
Keep the things that explain intent: source files, the README, the manifest, and
.gitlab-ci.yml. That last one is a genuinely GitLab-flavoured tip — the CI config is where
build steps, test commands, deploy targets and environment assumptions all live in one place. Include it
and the model can answer "why does this fail in CI but pass locally" instead of guessing.
The directory-view toggle is the other half of this. Switched to Full, the output includes
the complete repository structure with your selected files marked, so the model can see that a
payments module exists even though you didn't include it — useful context, cheap in tokens.
Switched to Filtered, only what you selected appears. Full is usually the better default
when you've selected one service out of a monorepo; filtered is tidier when you're sending a focused
handful of files.
The Jobs This Is Actually Good At
- Landing on an unfamiliar project. Select the source directory, the README and the CI config, then ask for a walkthrough of the entry points and where a request flows once it arrives. Twenty minutes of orientation, compressed into one prompt.
- Reviewing a merge request with its surroundings. A diff tells you what changed; it doesn't tell you what else calls the function that changed. Export the touched directory and its neighbours, paste the diff alongside it, and you get review comments about consequences rather than style.
- Writing the documentation nobody wrote. Feed a module in and ask for a README, an architecture note, or docstrings that match the code's existing conventions rather than inventing new ones.
- Generating tests. Include the module plus two or three existing test files. The second part is what makes the output usable — the model copies your fixtures, naming and assertion style instead of producing something that doesn't fit the suite.
- Migration and upgrade work. Framework version bumps, a language rewrite, swapping an ORM. These need whole-codebase visibility to catch every call site, which is exactly what a single text export gives you.
- Audits. Ask where secrets are read, which endpoints skip auth, or what still hits a deprecated internal API. Broad questions like these are unanswerable file by file.
In most of these, the interesting part is one service directory rather than the whole group. Select that
subtree, leave the rest, and check the token count before you paste — it's generated with the
gpt-tokenizer library, so it's a real count you can compare against your model's context
window instead of a guess. It's the same output whether you export GitLab code for an AI review pass or
turn a GitLab project into a text file for ChatGPT, Claude or Gemini — one file, and you can read it
before you send it.
The Files Sitting Next to Your Code
Repositories aren't only source files. Config, schemas, seed data and specs get committed alongside, and some of them read badly when dumped raw. Structured formats land better as Markdown: JSON to Markdown for config and API payloads, XML to Markdown for the Maven, Android and legacy SOAP files that never went away, CSV to Markdown for seed data and exports, and HTML to Markdown for templates and generated docs. Specs that arrived as a PDF convert too, and a ZIP archive can be flattened straight into text. File2Txt handles the lot if you'd rather not pick a page.
Frequently Asked Questions
How do I convert a GitLab repository to a text file?
Paste the project URL above and the file tree loads as a checkbox list. Select the files you want and export one text file with the directory structure at the top and each file underneath, headed by its path. Free, no install, no sign-up.
Does it work with self-hosted GitLab?
Not directly. This page currently calls the gitlab.com API. For a self-managed instance, clone or export the project and use the local folder converter; it produces the same structured output without uploading the source.
How do I convert a private GitLab project?
Supply a personal access token with the read_repository scope. Create it under Preferences → Access Tokens, give it the shortest expiry that covers your session, and delete it afterwards. Read-only is all this needs — a token with write or API-wide scope is more exposure than the task requires.
Why use this instead of cloning the repo?
Cloning gets you a working tree, which is the wrong shape for the job. What a model wants is one document containing the structure and the contents together, with the noise removed. Cloning also pulls the full history and every dependency — usually far more bytes than the source you actually want to reason about.
Does it handle subgroups and nested project paths?
Yes. GitLab's nested group structure means project paths run several segments deep, and the full path is what identifies the project — paste the complete URL from your browser's address bar rather than assembling one by hand, and the lookup resolves correctly.
Can I convert a merge request diff instead of the whole project?
Not from this page — it works on the repository tree at a given ref. For review work the usual pattern is to convert the files a merge request touches, paste that as context, then paste the diff itself underneath. The model needs the surrounding code to judge a change, and a diff alone rarely provides it.
Everything Else in the Toolkit
Code on GitHub instead? The GitHub repo to text converter works the same way. Only on your machine, or on a self-managed instance you've cloned? Use the local directory converter. Need the documentation site rather than the source that generates it? Web2Txt scrapes a URL into Markdown.
For the longer arguments behind all this, there's a guide on feeding a repository into an AI model, one on turning a codebase into an LLM-ready file, a complete guide to converting repositories for LLMs, and a broader piece on preparing files for AI tools.
Repo2Txt is built and maintained by v12hero, an independent developer building privacy-first native and web apps.