Lokaler Ordner-zu-Text-Konverter

Lokalen Ordner in Text umwandeln: Ihre Codebasis in einer Datei, ohne sie hochzuladen

Richten Sie das hier auf einen Ordner auf Ihrem Rechner und Sie bekommen eine einzige Textdatei zurück: oben ein Verzeichnisbaum, darunter jede ausgewählte Datei, jeweils getrennt durch eine Kopfzeile mit ihrem Pfad. Wie Sie es auch nennen — eine Codebasis in einer Datei zusammenfassen, Quelldateien aneinanderhängen, ein Verzeichnis zu einem Dokument verschmelzen — das ist die ganze Idee. Es ist das Format, mit dem ein LLM am besten umgeht, weil das Modell die Form des Projekts und die Inhalte gleichzeitig sieht und nachvollziehen kann, wie eine Datei mit der anderen zusammenhängt.

Es ist kostenlos, es gibt keine Anmeldung, und es ist nichts zu installieren. Ordner auswählen, abwählen, was das Modell nicht braucht, und das Projekt als eine einzige Textdatei exportieren, die Sie überall einfügen können.

Der Teil, um den es den meisten geht: Es wird nichts hochgeladen. In dieser Kette gibt es keinen Server. Ihre Dateien werden im Browser gelesen, im Arbeitsspeicher zusammengesetzt und Ihnen zurückgegeben. Wenn Sie Online-Konverter bisher gemieden haben, weil die Codebasis einem Kunden gehört, unter einer Geheimhaltungsvereinbarung steht oder schlicht nicht Ihre ist, um sie in einen fremden Dienst zu kippen — dieser Einwand greift hier nicht. Der nächste Abschnitt erklärt genau, warum, denn „vertrauen Sie uns, das ist sicher“ ist keine Antwort, die irgendjemand akzeptieren sollte.

Wie ein Konverter eine private Codebasis in Text umwandelt, ohne sie hochzuladen

Moderne Browser können Dateien von der Platte lesen, ohne sie irgendwohin zu schicken. Wenn Sie einen Ordner auswählen, übergibt der Browser der Seite eine Liste von Dateihandles. Jedes davon wird mit der Standard-API FileReader gelesen, die die Bytes im Speicher des Tabs zu einer Zeichenkette dekodiert. Der Verzeichnisbaum, die Tokenzahl, das Aneinanderhängen — all das passiert in JavaScript, das auf Ihrem Rechner läuft. Kein fetch, kein XHR, kein API-Endpunkt, kein Analytics-Aufruf an Dritte, der Dateiinhalte mitnimmt. Öffnen Sie beim Konvertieren den Netzwerk-Tab Ihres Browsers und Sie sehen ihn leer bleiben.

Dieser Mechanismus hat über den Datenschutz hinaus ein paar nützliche Nebenwirkungen:

• Es funktioniert offline. Sobald die Seite geladen ist, können Sie das Netzwerkkabel ziehen. Die Konvertierung läuft weiter. Praktisch auf einem Rechner ohne Netzanbindung oder in einem abgeschotteten Firmennetz.
• Keine Upload-Grenzen, keine Rate-Limits. Es gibt kein API-Kontingent zu erschöpfen, weil es keine API gibt. Die einzige Obergrenze sind der Speicher Ihres Browsers und Ihre Geduld.
• Es funktioniert mit Code, der nie committet wurde. Ein Wegwerf-Branch, ein nicht versioniertes Experiment, ein Ordner, der nie ein git init gesehen hat — an all das kommt der GitHub-Repo-zu-Text-Konverter nicht heran, weil er aus der GitHub-API liest. Dieser hier liest von der Platte und interessiert sich deshalb überhaupt nicht für Ihre Versionsverwaltung.
• Nichts bleibt zurück. Schließen Sie den Tab und der Zustand ist weg — kein Verlauf zum Löschen, kein Konto, das eine Kopie Ihres Quellcodes hält.

Drei Wege, ein Projekt hineinzubekommen

Nehmen Sie die Verzeichnisauswahl, um zu einem Ordner zu navigieren, oder ziehen Sie den Ordner direkt aus Finder oder Explorer auf die Ablagefläche. Beides läuft den Baum rekursiv ab, Sie bekommen also das ganze Projekt samt verschachtelter Unterverzeichnisse, nicht nur die oberste Ebene.

Sie können auch ein ZIP-Archiv ablegen, das dann im Browser entpackt wird — praktisch, wenn Ihnen jemand ein Projekt gemailt hat oder Sie es lieber gar nicht erst entpacken wollen. Eine Unterscheidung sollten Sie kennen: Nehmen Sie diese Seite, wenn das Archiv ein Code-Projekt enthält, denn dann wollen Sie den Verzeichnisbaum und Pfad-Kopfzeilen je Datei. Ist es ein Haufen Dokumente — Berichte, Tabellen, PDFs — passen ZIP zu Text oder ZIP zu Markdown besser, denn die holen den lesbaren Inhalt aus jedem Dokument heraus, statt Dateien als Quellcode zu behandeln.

Jede IDE, jeder Editor — es will nur einen Ordner

Es gibt kein Plug-in zu installieren und keine Erweiterung freizugeben, denn das hier klinkt sich gar nicht in Ihren Editor ein. Es nimmt ein Verzeichnis. Ob dieses Verzeichnis zufällig ein VS-Code-Workspace, ein IntelliJ-IDEA- oder PyCharm-Projekt, eine Visual-Studio-Solution, ein Android-Studio-Modul, ein Xcode-Projekt, ein Eclipse-Workspace oder ein Ordner ist, den Sie nur je in Neovim geöffnet haben — es sind dieselben Dateien auf derselben Platte. Auswahl draufrichten, fertig.

Das gehört ausgesprochen, weil „mein VS-Code-Projekt als eine TXT exportieren“ und „ein IntelliJ-Projekt in eine Datei exportieren“ Fragen sind, die Leute zuerst ihrem Editor stellen. Editoren sind dafür meist die falsche Adresse. Sie exportieren Dateien, eine nach der anderen. Ein paar haben eine Marketplace-Erweiterung, die es halb löst, die meisten nicht, und jede löst es anders — eine Antwort für die eine IDE ist wertlos, sobald Sie wechseln. Der Ordner ist der gemeinsame Nenner.

Es ist außerdem der bessere Zug, als das Projekt zu zippen und zu verschicken. Ein Archiv ist unter Entwicklern in Ordnung, aber ein Chat-Modell will Text und keinen Container, und wer es reviewt, muss es erst entpacken, bevor eine Zeile lesbar ist. Eine zusammengeführte .txt ist direkt lesbar: in eine Unterhaltung einfügen, an ein Ticket hängen, in einen E-Mail-Verlauf werfen. Und wenn Ihnen jemand schon ein ZIP geschickt hat, können Sie das direkt auf diese Seite ziehen, statt es vorher auszupacken.

Räumen Sie vor dem Generieren gründlich auf

Das ist der Schritt, den die Leute überspringen, und der entscheidet, ob die Ausgabe brauchbar wird. Im Auswahlbaum ist zunächst alles angehakt — standardmäßig sind Sie also dabei, eine Menge Dinge aufzunehmen, die kein Modell sehen muss.

Eines arbeitet hier für Sie. Enthält der Ordner eine .gitignore, wird sie gelesen und ihre Regeln werden angewendet — auch verschachtelte weiter unten im Baum, jeweils auf ihr eigenes Verzeichnis beschränkt, Kommentarzeilen übersprungen. In einem normalen Repo verschwinden damit still die schlimmsten Übeltäter, bevor Sie irgendetwas anfassen, denn was einen Dump aufbläht, ist meist genau das, was Sie Git schon zu ignorieren gesagt haben. Das Verzeichnis .git selbst wird immer ausgeschlossen.

Verlassen Sie sich aber nicht allein darauf. Ein Ordner ohne .gitignore — ein entpacktes ZIP, eine Übergabe vom Dienstleister, ein Verzeichnis, das nie ein Repo war — bekommt nichts von diesem Schutz. Und viel Lärm ist völlig legitim in Git versioniert. Gehen Sie den Baum durch und wählen Sie ab:

• node_modules, vendor, .venv, site-packages. Abhängigkeitsbäume sind riesig und nichts davon ist Ihr Code. Ein ungefiltertes node_modules allein kann hunderttausende Tokens fremden Quellcodes sein. Es überschwemmt das eigentliche Projekt, und die Antworten des Modells driften in Richtung Bibliotheks-Interna.
• Build-Artefakte — dist, build, .next, target, out, Coverage-Berichte. Das ist Ihr eigener Code, minifiziert oder transpiliert, also doppelt. Reines Rauschen.
• Lockfiles. package-lock.json, yarn.lock, poetry.lock, Cargo.lock. Tausende Zeilen Hashes mit nahezu keiner semantischen Information. Behalten Sie das Manifest (package.json, pyproject.toml) — das ist der Teil, der dem Modell sagt, auf welchem Stack Sie sitzen.
• Generierter Code und Fixtures — Protobuf-Ausgaben, GraphQL-Codegen, Datenbankmigrationen, große Seed- oder Snapshot-Dateien.
• Alles mit Geheimnissen. Es wird zwar nichts übertragen, aber die Ausgabedatei landet am Ende in einem Chatfenster. Lassen Sie .env draußen.

Um Binärdateien wird sich gekümmert: Bilder, Schriften, Kompilate und Ähnliches werden anhand der Endung herausgefiltert, bevor sie überhaupt in den Baum gelangen, und was doch durchrutscht, fängt eine Prüfung auf Nullbytes ab und ersetzt es durch einen kurzen Platzhalter, statt Müll auszukippen. Dateien über 1 MB bekommen ebenfalls einen Platzhalter mit Größenangabe, damit nicht eine versprengte CSV Ihr ganzes Kontextbudget frisst.

Für den Verzeichnisbaum oben in der Ausgabe gibt es außerdem einen Umschalter: gefiltert zeigt nur, was Sie ausgewählt haben, vollständig zeigt die komplette Struktur mit markierter Auswahl. Vollständig ist die bessere Wahl bei Architekturfragen, denn dann sieht das Modell, dass es ein Verzeichnis tests/ gibt, auch wenn Sie es nicht aufgenommen haben. Gefiltert ist besser, wenn das Modell eng fokussiert bleiben soll und sonst nichts.

Im Kontextfenster bleiben

Die erzeugte Ausgabe kommt mit einer echten Tokenzahl, berechnet von der Bibliothek gpt-tokenizer und nicht per Schätzung „Zeichen durch vier“. Gleichen Sie sie mit Ihrem Modell ab, bevor Sie einfügen. Das ist ein deutlich besserer Arbeitsablauf als einfügen, warten und eine Längenfehlermeldung zurückzubekommen.

Grobe Orientierung, wie viel Sie schicken sollten. Schicken Sie das ganze Projekt, wenn es bequem hineinpasst und Ihre Frage architektonisch ist — „wo wird Authentifizierung eigentlich durchgesetzt“, „was würde brechen, wenn ich diese Schnittstelle ändere“, „erkläre den Datenfluss vom Request bis zur Datenbank“. Für ehrliche Antworten darauf braucht das Modell das Gesamtbild, und ein Teil-Dump erzeugt selbstbewusste Vermutungen über Dateien, die es nie gesehen hat.

Schicken Sie eine Scheibe, wenn die Frage lokal ist — ein Modul plus die Tests, die es abdecken, plus die zwei oder drei Dateien, aus denen es importiert. Weniger Kontext heißt schärfere Antworten und weniger Abdriften, und aus 5.000 gut gewählten Tokens holen Sie meist mehr heraus als aus 200.000 wahllosen.

Monorepos brauchen ein bewusstes Vorgehen. Konvertieren Sie nicht die Repo-Wurzel. Nehmen Sie ein Paket nach dem anderen, und wenn dieses Paket von einer gemeinsam genutzten internen Bibliothek abhängt, legen Sie deren öffentliche Oberfläche daneben. Brauchen Sie paketübergreifenden Kontext, hilft ein Trick mit zwei Durchgängen: einmal der vollständige Baum mit fast keinen ausgewählten Dateien — das gibt dem Modell eine Landkarte — und danach ein zweiter, dateireicher Durchgang für das Paket, in dem Sie tatsächlich arbeiten.

Warum nicht einfach cat oder ein Shell-Skript?

Berechtigte Frage, und manchmal lautet die ehrliche Antwort: Sollten Sie. Wenn Sie drei bekannte Dateien zusammenhängen wollen, ist cat auth.py models.py routes.py > out.txt schneller, als einen Browser zu öffnen. Niemand will Ihnen das ausreden.

Es hört in dem Moment auf, sich zu lohnen, in dem Sie es auf ein ganzes Projekt richten. Lassen Sie find . -type f -exec cat {} + auf ein echtes Repo los, und das bekommen Sie:

• Binärdateien mitten in Ihrem Quellcode. PNGs, Schriften, Objektdateien, ein versprengtes SQLite-Fixture — alles als Text dekodiert, alles Zeichensalat. Danach fangen Sie an, eine Whitelist für Endungen zu pflegen.
• Der komplette Abhängigkeitsbaum. node_modules, .venv, vendor, target und der Inhalt von .git selbst. Um die auszuschließen, schreiben Sie Prune-Ausdrücke und halten sie für jedes Projekt aktuell, an dem Sie arbeiten. Hier beschreibt Ihre .gitignore genau das schon, verschachtelte Dateien eingeschlossen, und sie wird für Sie angewendet.
• Keine Ahnung, wie groß es ist. Aneinanderhängen liefert Bytes, keine Tokens, und Zeichen durch vier ist eine Schätzung, die in beide Richtungen danebenliegt. Dass es nicht passt, erfahren Sie, wenn das Modell es ablehnt.
• Gezielte Auswahl kostet mehr Skript. „Alles unter src außer dem generierten API-Client, plus die zwei Konfigurationsdateien im Wurzelverzeichnis“ ist noch ein Flag und noch eine Regex. Ein Auswahlbaum erledigt das in etwa vier Klicks.
• Keine Landkarte am Anfang. Rohes Aneinanderhängen ergibt eine Textwand ohne Strukturkopf, das Modell kann also nicht erkennen, wo eine Datei endet und die nächste beginnt oder wie das Projekt aufgebaut ist. Pfadgetrennte Abschnitte und ein Verzeichnisbaum sind das meiste davon, was einen Dump lesbar macht.

Alles davon lässt sich bauen, und viele haben es gebaut. Es ist ein Nachmittag Skripten und danach ein kleines Werkzeug, das Sie pflegen. Die Frage ist, ob Sie das Skript wollen oder die Ausgabe.

Wofür die Leute das tatsächlich einsetzen

• Die Codebasis, die Sie gerade geerbt haben. Jemand ist gegangen, und nun gehört Ihnen ein Dienst mit 40.000 Zeilen. Konvertieren, einfügen und nach den Einstiegspunkten fragen, den zentralen Abstraktionen und den drei Dingen, die einen neuen Maintainer am meisten überraschen würden. Das orientiert schneller als jedes Übergabedokument, das Sie bekommen werden.
• Dokumentation aus echtem Quellcode. READMEs verrotten, weil sie einmal geschrieben werden. Erzeugen Sie sie aus dem Code, der jetzt existiert — Architekturüberblicke, Modulzusammenfassungen, eine korrekte Liste der Umgebungsvariablen, die die Anwendung wirklich liest.
• Tests für ungetesteten Code. Nehmen Sie das Modul plus eine vorhandene Testdatei als Stilvorlage mit hinein. Das Modell übernimmt Ihr Framework, Ihre Benennung, Ihre Fixture-Muster, statt eine Testkonvention zu erfinden, die Sie nicht verwenden.
• Migrationen und Refactorings planen. Klassenkomponenten zu Hooks, JavaScript zu TypeScript, ein ORM zum nächsten. Ein Modell, das jede Aufrufstelle sieht, gibt Ihnen einen echten Plan statt einer generischen Checkliste.
• RAG und Embeddings. Eine einzelne saubere Textdatei mit pfadgetrennten Abschnitten lässt sich unkompliziert an genau diesen Trennern chunken und in eine Vektordatenbank schieben.

Wenn Sie fertig sind, kopieren Sie die Ausgabe in die Zwischenablage oder laden sie als .txt-Datei herunter — aufhebenswert, wenn Sie denselben Kontext über mehrere Unterhaltungen hinweg wiederverwenden.

Code ist nur die halbe Miete

Bei den meisten echten Fragen zu einem Projekt sind auch Dinge im Spiel, die keine Quelldateien sind. Die Spezifikation steckt in einem PDF, das Schema in einer JSON-Datei, die Konfiguration in XML, die Daten in einer CSV. Konvertieren Sie die getrennt und fügen Sie sie neben Ihrem Codebasis-Dump ein: PDF zu Markdown für Spezifikationen und Herstellerdokumentation, Word zu Markdown für Anforderungsdokumente, JSON zu Markdown für API-Payloads und Schemata, XML zu Markdown für alte Konfigurationen, CSV zu Markdown für Beispieldaten und HTML zu Markdown für exportierte Seiten. Wenn Sie sich nicht für ein Format entscheiden wollen, nimmt File2Txt alles, was Sie ihm vorwerfen.

Häufige Fragen

Wie wandle ich einen Ordner in eine Textdatei um?

Wählen Sie oben ein Verzeichnis, und Sie bekommen dessen Baum als Liste mit Kontrollkästchen. Haken Sie die gewünschten Dateien an und exportieren Sie eine einzige Textdatei — zuerst die Verzeichnisstruktur, dann jede Datei unter einer Kopfzeile mit ihrem Pfad. Kostenlos, ohne Anmeldung, nichts zu installieren.

Wird mein Code auf einen Server hochgeladen?

Nein. In dieser Kette gibt es überhaupt keinen Server. Der Ordner wird im Browser gelesen, die Ausgabe im Browser zusammengesetzt, und nichts geht über das Netz — Sie können die Entwicklerwerkzeuge öffnen und zusehen, oder die Internetverbindung nach dem Laden der Seite trennen, es funktioniert trotzdem. Das ist der Unterschied zum GitHub-Konverter, der die API aufrufen muss.

Ist es unbedenklich, eine Firmen-Codebasis online zu konvertieren?

Diese Seite ist die Variante, die diese Frage mit Technik beantwortet statt mit einem Versprechen: Die Dateien verlassen den Rechner nie, es gibt also nichts, worin Sie uns vertrauen müssten. Worauf es weiterhin ankommt, ist der nächste Schritt — wenn Sie die Ausgabe in ein gehostetes Modell einfügen, geht sie an diesen Anbieter. Prüfen Sie also die Richtlinie Ihres Unternehmens und entfernen Sie vorher Geheimnisse.

Kann ich ein ganzes Projekt samt Unterordnern konvertieren?

Ja, der komplette Baum wird durchlaufen und jede Ebene ist auswählbar. Einen Ordner abzuwählen entfernt alles darunter mit einem Klick — so werden Sie node_modules oder .git los, ohne sich durch die Kinder zu wühlen. Der Token-Zähler aktualisiert sich dabei, Sie sehen die Wirkung also sofort.

Welche Browser können einen ganzen Ordner auswählen?

Die Ordnerauswahl nutzt das Verzeichnis-Upload-Attribut, das Chrome, Edge, Firefox und Safari seit Jahren unterstützen — jeder aktuelle Desktop-Browser funktioniert also. Die Lücke sind mobile Browser: Weder iOS noch Android bietet eine Ordnerauswahl an. Auf dem Handy zippen Sie das Verzeichnis und nehmen stattdessen ZIP zu Text.

Wie groß darf eine Datei sein?

Es gibt keinen Upload, also auch keine Upload-Grenze — die Schranke sind der Speicher Ihres Rechners und die Textmenge, die Sie hinterher irgendwo sinnvoll einfügen können. In der Praxis wird der Token-Zähler lange vor dem Browser zur echten Grenze. Ein Repository, dessen nützlicher Quellcode unter einem Megabyte liegt, deckt die meisten Projekte ab, sobald die Abhängigkeiten abgewählt sind.

Der Rest des Werkzeugkastens

Liegt der Code gehostet statt lokal, erledigen der GitHub-zu-Text-Konverter und der GitLab-zu-Text-Konverter dieselbe Arbeit gegen ein entferntes Repository, private mit Token eingeschlossen. Für Dokumentation, die nur im Web existiert, holt Web2Txt eine URL als sauberes Markdown — kombinieren Sie eine so geholte API-Referenz mit Ihrem lokalen Quellcode, und ein Coding-Assistent sieht beide Seiten auf einmal.

Im Blog steht mehr, wenn Sie tiefer einsteigen wollen: eine Codebasis in eine LLM-taugliche Datei verwandeln, eine Schritt-für-Schritt-Anleitung zum Konverter von Ordner zu Text, ein Leitfaden zum Einspeisen eines ganzen Repositories in eine KI und der allgemeine Leitfaden zur Umwandlung von Dateien in Text für alles, was kein Code ist.

Repo2Txt wird entwickelt und gepflegt von v12hero, einem unabhängigen Entwickler, der native und Web-Apps mit Fokus auf Datenschutz baut.