JSON in Text umwandeln: Syntax raus, Inhalt bleibt
Öffnen Sie einen JSON-Export einmal im Editor und zählen Sie nach, was da eigentlich steht. Geschweifte Klammern, eckige Klammern, doppelte Anführungszeichen um jeden Schlüssel und jeden Zeichenkettenwert, nach jedem Paar ein Komma, dazwischen ein Doppelpunkt — und in einer formatierten Datei zusätzlich Tausende führende Leerzeichen. Bei einem typischen Export mit vielen Datensätzen entfällt ein erheblicher Teil der Bytes auf Strukturzeichen, die keinerlei Information tragen, an der Ihnen gelegen wäre.
Diese Seite macht genau eine Sache: Sie nimmt eine .json-Datei und gibt Ihnen den
lesbaren Inhalt zurück, ohne all das drumherum. Keine Überschriften, keine Tabellen, keine
senkrechten Striche — nur die Werte, in der ursprünglichen Reihenfolge, gerade so weit
beschriftet, dass sie verständlich bleiben. Das ist die richtige Ausgabe, wenn am Ende ein
Embedding-Modell, ein Suchindex, ein Auswertungsskript oder irgendeine Pipeline steht, für die
Satzzeichen nur Rauschen sind. Kostenlos, ohne Anmeldung, bis 50 MB, nichts wird gespeichert.
Was rausfliegt und was übrig bleibt
Die Regeln sind knapp genug, um sie im Kopf zu behalten — und darauf kommt es an, wenn Sie abschätzen wollen, ob die Ausgabe zu Ihrer Pipeline passt:
- Weg: jedes
{,},[,], jedes Anführungszeichen, jedes Komma, jeder Doppelpunkt. Dazu die Einrückung, die in einer formatierten Datei einen erstaunlichen Anteil der Gesamtgröße ausmachen kann. - Bleibt: Zeichenketten, Zahlen, Wahrheitswerte — die Nutzlast.
- Bleibt, aber ohne Pfad: die Feldnamen. Sie überleben als kurze Beschriftung,
statt ersatzlos gestrichen zu werden, denn ein
refund_reasonvor einem Satz sagt sowohl einem Leser als auch einem Embedding-Modell etwas. Verloren geht der Pfad durch die Verschachtelung, nicht der Name selbst. - Zusammengefaltet:
null, leere Zeichenketten, leere Arrays. Im rohen JSON stehen sie in jedem Datensatz, der sie hat, aufs Neue da; in der Textausgabe beanspruchen sie keinen Platz mehr. - Linearisiert: die Verschachtelungstiefe. Ein Wert sechs Ebenen tief und ein Wert ganz oben landen als benachbarte Zeilen nebeneinander. Das ist der Handel: Sie geben den Baum her und bekommen sauberen Fließtext dafür.
Warum Syntax Embeddings schadet
Hier geht es ausnahmsweise nicht um Ordentlichkeit, sondern um Ergebnisse. Wenn Sie einen Textabschnitt einbetten, kodiert das Modell alles, was darin steht. Geben Sie ihm einen rohen JSON-Datensatz, dann beschreibt ein guter Teil des entstehenden Vektors schlicht die Tatsache, dass hier JSON zu sehen war — Klammern, Schlüssel in Anführungszeichen, die grobe Silhouette einer Datenstruktur. Zwei Datensätze zu völlig verschiedenen Themen können im Vektorraum dicht beieinander liegen, nur weil sie dasselbe Schema teilen.
Nehmen Sie die Syntax weg, und das Embedding handelt vom Inhalt. Aus einem Support-Ticket werden die tatsächlichen Worte des Kunden plus ein paar Beschriftungen, und die semantische Suche darüber verhält sich endlich so, wie Sie es erwartet hatten. Am deutlichsten fällt das bei kurzen Datensätzen aus, wo das Verhältnis von Syntax zu Inhalt am schlechtesten ist — ein Objekt mit fünf Feldern und Werten aus je zwei Wörtern besteht überwiegend aus Satzzeichen.
Dieselbe Logik gilt fürs Chunking. Rohes JSON ist für Chunker mit fester Fenstergröße ausgesprochen unfreundlich, weil ein Schnitt mitten in ein Objekt fällt und ein verwaistes Klammerfragment hinterlässt. Flacher Text bricht an Satz- und Zeilengrenzen, also genau dort, wo ein Chunker es voraussetzt.
JSON in Text umwandeln für Suchindex und Textanalyse
Volltextsuchmaschinen zerlegen an Wortgrenzen und werfen Satzzeichen ohnehin weg — nur eben nicht immer sauber und nicht immer, bevor die Termstatistik schon schiefgezogen ist. Wer bereits bereinigten Text indexiert, bekommt vorhersagbare Termhäufigkeiten und erspart dem Analyzer unnötige Arbeit.
Bei allem Statistischen wiegt das Argument noch schwerer. Worthäufigkeiten, Sentiment-Analyse über einen Export von Produktbewertungen, Themenmodellierung auf einem Support-Ticket-Dump, Eigennamenerkennung in einem gescrapten Datenbestand — all das wird von Strukturtokens und von Feldern verfälscht, die Sie gar nicht mitgezählt haben wollten. Einmal JSON lesbar machen, und Sie haben ein Korpus statt einer Datenstruktur.
Was Sie vor der Auswertung möglichst noch löschen sollten: ISO-Zeitstempel, UUIDs und numerische IDs. Sie zerfallen beim Tokenisieren in bedeutungslose Bruchstücke und tauchen in wirklich jedem Datensatz auf — genau das Profil von etwas, das eine Häufigkeitstabelle gründlich verzerrt.
Das Argument Token-Budget
Wenn Sie einen großen Export in ein Modell schieben, ist flacher Text die günstigste Darstellung desselben Inhalts. Zwei Effekte tragen die Ersparnis. Erstens fallen die Strukturzeichen weg. Zweitens — und bei datensatzlastigen Dateien wiegt das schwerer — zahlen Sie nicht länger für die Wiederholung der Schlüssel in jedem einzelnen Objekt. Tausend Datensätze, die jeweils acht Feldnamen erneut aufführen, schleppen in der Rohdatei achttausend überflüssige Beschriftungen mit.
Der Token-Zähler sitzt direkt unter der Ausgabe, Sie können also konvertieren und nachsehen, bevor Sie irgendwo einfügen. Bei minifizierten API-Dumps und NDJSON-Logdateien fällt der Unterschied meist beträchtlich aus. Nur: Wenn Sie deshalb am Limit kratzen, weil die Datei schlicht riesig ist, rettet Sie keine Konvertierung — filtern Sie erst die Datensätze heraus, die Sie brauchen, und wandeln Sie dann um.
Wann flacher Text die falsche Wahl ist
Ehrlichkeit an dieser Stelle nützt mehr, als so zu tun, als gewänne die Konvertierung immer. Modelle lesen rohes JSON flüssig; es gehört zu den Formaten, von denen sie am meisten gesehen haben. Es gibt drei Situationen, in denen Sie die Syntax stehen lassen sollten:
- Sie lassen Code gegen die Daten schreiben. Typdefinitionen, Parser, Mapping-Funktionen, Validierungsschemata — dafür braucht es die exakten Schlüsselnamen, die exakte Verschachtelung und die exakten Typen. Fügen Sie die rohe Nutzlast ein oder eine gekürzte Stichprobe davon. Das Flachklopfen wirft genau das weg, worauf es dem Modell ankommt.
- Die Verschachtelung trägt die Bedeutung. Wenn es gerade darauf ankommt, unter welchem Elternknoten ein Wert hängt — Berechtigungen pro Rolle, Einstellungen pro Umgebung, ein Kategorienbaum —, dann zerstört das Flachklopfen die Antwort. Nehmen Sie stattdessen JSON zu Markdown: Dort bleibt die Hierarchie als Überschriften erhalten, und gleichförmige Datensatz-Arrays werden zu übersichtlichen Tabellen.
- Ein Mensch soll es lesen. Flacher Text ist für Maschinen optimiert. Wenn jemand das Ergebnis durchsehen soll, gewinnt Markdown ohne Diskussion.
Der Formatumschalter oben auf der Seite wechselt zwischen beiden und behält Ihre ausgewählte Datei, ein Vergleich kostet Sie also einen Klick statt eines zweiten Uploads.
Sperrige Dateien und wie sie sich verhalten
- Unicode-Escapes. Dateien aus älteren Bibliotheken kodieren alles jenseits
von ASCII als
\u00e9statt als das Zeichen selbst. Das wird wieder zu echten Buchstaben dekodiert, was bei Umlauten und generell bei nicht-englischen Daten einiges ausmacht. - Base64-Blobs. Bilder, PDFs oder Anhänge, die jemand in ein JSON-Feld geschmuggelt hat, sind riesig und enthalten keinen einzigen lesbaren Buchstaben. Entfernen Sie sie vor dem Hochladen, sonst beherrschen sie sowohl die Dateigröße als auch Ihre Token-Zahl.
- JSON im JSON, escapt. Verbreitet in Webhook-Nutzlasten und Logzeilen — ein Textfeld, dessen Inhalt selbst wieder ein serialisiertes Objekt ist. Es kommt als eine lange escapte Zeichenkette durch. Packen Sie dieses Feld vorher aus, wenn genau darin der interessante Teil steckt.
- Kaputte Dateien. Kommas am Ende, einfache Anführungszeichen, ein
NoneoderNaNim Python-Stil. Daran scheitert das Parsen komplett. Prüfen Sie die Datei vorher mit einem Linter, wenn ihre Herkunft unklar ist. - JSON Lines. NDJSON-Exporte eignen sich hier gut — gleichförmige Datensätze,
einer pro Zeile, schon nah an der gewünschten Form. Benennen Sie die Datei in
.jsonum oder fassen Sie die Zeilen vorher in einem Array zusammen.
Häufige Fragen
Wie wandle ich eine JSON-Datei in eine TXT-Datei um?
Ziehen Sie die .json in den Konverter oben, und die Werte kommen als lesbarer Text zurück — ohne geschweifte und eckige Klammern, ohne Anführungszeichen, Kommas und Doppelpunkte. Laden Sie das Ergebnis als .txt herunter. Kostenlos, ohne Anmeldung, 50 MB pro Datei, danach wird nichts aufbewahrt.
Warum überhaupt umwandeln, statt das JSON direkt zu nehmen?
Weil Syntaxzeichen totes Gewicht sind für alles, was Bedeutung liest statt Struktur. Embedding-Modelle, Klassifikatoren und Volltextindizes tokenisieren jedes Anführungszeichen und jedes Komma, verwässern damit die Vektoren und treiben die Kosten hoch, ohne Information beizusteuern. Wenn Ihr Abnehmer JSON parst, behalten Sie JSON — dieser Weg ist für die Pipelines, die das eben nicht tun.
Werden verschachtelte Objekte und Arrays flachgeklopft?
Ja. Verschachtelung ist Struktur, und Struktur ist genau das, was hier entfernt wird; ein tief verschachtelter Datensatz kommt daher als flache Folge beschrifteter Werte in Dokumentreihenfolge an. Die Schlüssel bleiben als Beschriftung stehen, damit die Werte deutbar bleiben, aber die Eltern-Kind-Beziehung zwischen ihnen wird nicht abgebildet. Bei tief verschachtelten Konfigurationsdateien tut das am meisten weh.
Funktioniert das auch mit JSON Lines oder NDJSON?
Nur wenn die Datei als Ganzes gültiges JSON ist. NDJSON ist ein Objekt pro Zeile ohne umschließendes Array und damit bewusst kein einzelnes JSON-Dokument, also lässt es sich auch nicht als eines parsen. Fassen Sie die Zeilen vorher in [ ] und trennen Sie sie durch Kommas — eine Zeile jq oder sed genügt —, dann klappt die Umwandlung ganz normal.
Und bei sehr großen Exporten?
Die Grenze liegt bei 50 MB pro Datei, und das ist eine Menge JSON — formatierte Exporte bestehen größtenteils aus Leerraum und Struktur, der lesbare Inhalt darin macht nur einen Bruchteil der Dateigröße aus. Liegen Sie darüber, filtern Sie die benötigten Datensätze vorher mit jq heraus, statt willkürlich zu zerschneiden und dabei das umschließende Array zu verlieren.
Verwandte Konverter
Falls Ihr JSON in Wahrheit eine Tabelle im Kostüm ist, führt der Umweg über einen CSV-Export und CSV zu Text zum saubereren Ergebnis. Für das andere strukturierte Format mit demselben Problem in anderer Form gibt es XML zu Text, und für gespeicherte Seiten HTML zu Text. File2Txt nimmt jedes unterstützte Format, wenn Sie sich keine Seite aussuchen möchten.
Und wenn die Datei eine von vielen in einem Projekt ist, dann ist sie einzeln zu konvertieren vermutlich die falsche Einheit. Mit dem Konverter für lokale Verzeichnisse und dem GitHub-zu-Text-Konverter wählen Sie das JSON und den Code, der es liest, in einem Durchgang aus. Für Seiten im Netz holt Web2Txt eine URL direkt ab, und der Leitfaden zur Aufbereitung von Dateien für LLMs behandelt den allgemeinen Fall.
Repo2Txt wird entwickelt und gepflegt von v12hero, einem unabhängigen Entwickler, der native und Web-Apps mit Datenschutz an erster Stelle baut.