CSV zu JSON Konverter

So wandeln Sie CSV online in JSON um

CSV ist das Format, das Tabellenkalkulationen, Datenbanken und CRM-Systeme standardmäßig ausspucken, weil es nichts weiter als Text ist: eine Kopfzeile, danach eine Zeile pro Datensatz, mit einem Trennzeichen zwischen den Spalten. JSON ist das, was moderne Web-Apps, REST-APIs und JavaScript selbst tatsächlich erwarten: ein Array aus Objekten, jedes mit Feldnamen als Schlüssel. Dieser Konverter überbrückt beide Formate vollständig in Ihrem Browser und macht aus den Zeilen eines CSV- oder TSV-Exports ein sauberes, strukturiertes JSON-Array, in der Zeit, die ein Klick auf eine Schaltfläche braucht.

Die Lücke zwischen beiden Formaten taucht im Arbeitsalltag ständig auf. Ein Backend-Entwickler bekommt von der QA-Abteilung eine Tabelle mit Testnutzern und braucht sie als JSON-Fixture für einen Integrationstest. Ein Frontend-Entwickler erhält einen aus einem Warenwirtschaftssystem exportierten Produktkatalog und braucht daraus ein Array aus Objekten, um Karten zu rendern. Eine Datenanalystin zieht einen Bericht aus einem CRM und muss ihn in ein Skript einspeisen, das ausschließlich JSON liest. Niemand von ihnen möchte für diese zehn Sekunden dauernde Aufgabe einen eigenen Parser schreiben oder ein Kommandozeilen-Werkzeug installieren.

Schritt-für-Schritt-Anleitung zur CSV-zu-JSON-Umwandlung

1. CSV einfügen. Fügen Sie Ihre Zeilen in das Feld "CSV-Eingabe" ein, egal ob per Kopieren aus Excel, Google Sheets, einem Datenbank-Export oder einer TSV-Datei, bei der Tabulatoren statt Kommas die Spalten trennen.
2. Trennzeichen festlegen. Belassen Sie die Einstellung bei "Automatisch erkennen" für die meisten Dateien, oder wählen Sie direkt Komma, Tab, Semikolon oder Pipe, wenn Sie bereits wissen, welches Zeichen Ihr Export verwendet.
3. Kopfzeilen- und Typ-Optionen wählen. Lassen Sie "Erste Zeile als Kopfzeile" aktiviert, um Ihre Kopfzeile als JSON-Schlüssel zu verwenden, und schalten Sie "Zahlen erkennen" je nachdem um, ob numerisch aussehende Felder wie Alter oder Preise zu echten JSON-Zahlen werden oder als Text bestehen bleiben sollen.
4. Auf "In JSON umwandeln" klicken. Der Parser baut das Array in deutlich unter einer Sekunde auf, eingerückt nach Ihrer Wahl, und zeigt es im Feld "JSON-Ausgabe" darunter an.
5. Ergebnis kopieren oder herunterladen. Holen Sie es sich mit einem Klick auf "Kopieren", oder nutzen Sie "Als .json herunterladen", um es als Datei zu speichern, die Sie weitergeben, anhängen oder direkt in ein anderes Werkzeug importieren können.

Jeder dieser Schritte läuft auf Ihrem eigenen Gerät ab. Es gibt keinen Upload, keine Warteschlange auf einem Server und keine künstliche Zeilenbegrenzung, da das JavaScript in Ihrem Tab die gesamte Arbeit übernimmt.

Warum das Trennzeichen zählt: Komma, Semikolon, Tab und Pipe

"CSV" ist in Wirklichkeit eher eine Familie von Formaten als ein einziger strenger Standard, und das Zeichen zwischen Ihren Spalten ist keineswegs immer ein Komma, ganz gleich, was die Dateiendung behauptet. Genau deshalb bringt dieses Werkzeug eine automatische Erkennung mit: Es untersucht die ersten fünf Zeilen Ihres eingefügten Textes, zählt, wie oft jedes Kandidaten-Zeichen (Tab, Komma, Semikolon, Pipe) außerhalb von Anführungszeichen vorkommt, und wählt das Zeichen, das über diese Zeilen hinweg am konsistentesten auftritt, statt einfach das insgesamt häufigste zu nehmen. Eine Datei, in der jede Zeile exakt drei Semikolons und null Kommas enthält, ist ein klares Signal, selbst wenn irgendwo in einem Notizfeld zufällig auch ein Semikolon steckt.

Die häufigste Überraschung ist das Semikolon, und wer aus Deutschland, Österreich oder der Schweiz CSV-Dateien aus Excel bekommt, kennt diesen Effekt vermutlich schon. Windows koppelt Excels Standard-Listentrennzeichen an die Regionaleinstellungen des Systems, und im deutschsprachigen Raum ist das Komma bereits als Dezimaltrennzeichen belegt, ein Preis wird also als 12,50 geschrieben statt als 12.50. Würde Excel gleichzeitig das Komma als Spaltentrenner verwenden, würde eine einzelne Preisspalte bei jedem Export lautlos in zwei Spalten zerfallen. Um genau diese Kollision zu vermeiden, exportiert Excel in deutscher, österreichischer, Schweizer und den meisten anderen kontinentaleuropäischen Locale-Einstellungen CSV-Dateien mit Semikolon als Trennzeichen, obwohl die Datei weiterhin auf .csv endet. Eine Zeile wie Name;Stadt;Gehalt mit einem Wert von 4500,75 ist damit ein vollkommen normaler Export aus einer deutschen Gehaltstabelle und kein Zeichen einer kaputten Datei.

Rät die automatische Erkennung einmal falsch, was am ehesten bei sehr kurzen Dateien mit nur einer oder zwei Zeilen zum Testen passiert, wählen Sie das richtige Trennzeichen einfach selbst aus dem Dropdown-Menü. Der Rest der Parsing-Logik, Anführungszeichen, maskierte Anführungszeichen und Typ-Erkennung, funktioniert unabhängig vom gewählten Trennzeichen exakt gleich.

Anführungszeichen, eingebettete Kommas und Zeilenumbrüche

Ein naiver CSV-Parser teilt jede Zeile einfach am Trennzeichen, und genau das bricht in dem Moment, in dem ein Feld das Trennzeichen selbst enthält. Echte CSV-Daten sind voll davon: eine Spalte "Nachname, Vorname", eine Adresse mit einem Komma vor der Stadt, eine Produktbeschreibung mit einer kommagetrennten Liste von Merkmalen. Die vor Jahrzehnten standardisierte Lösung, heute meist als RFC 4180 bezeichnet, besteht darin, jedes Feld, das das Trennzeichen enthält, in doppelte Anführungszeichen zu setzen. Dieser Konverter setzt diese Regel als echte, zeichenweise arbeitende Zustandsmaschine um statt als simplen String-Split.

Konkret wandelt sich eine Zeile wie "Müller, Anna",42,"Frankfurt am Main, Hessen" korrekt in ein Namensfeld "Müller, Anna" und ein Ortsfeld "Frankfurt am Main, Hessen" um, jedes bleibt ein einziger Wert statt in zusätzliche Spalten zu zerfallen. Der Parser verfolgt beim zeichenweisen Lesen eine inQuotes-Markierung und behandelt ein Komma nur dann als Feldtrenner, wenn diese Markierung gerade nicht gesetzt ist.

Maskierte Anführungszeichen und mehrzeilige Felder

Zwei verwandte Sonderfälle kommen in echten Exporten ständig vor. Erstens wird ein tatsächliches doppeltes Anführungszeichen innerhalb eines Feldes als zwei aufeinanderfolgende Anführungszeichen geschrieben, sodass "Sie sagte ""Hallo"" zu mir" zu dem einzelnen Feld Sie sagte "Hallo" zu mir wird, wobei die doppelten Zeichen zu einem einzigen zusammengefasst werden. Zweitens darf ein in Anführungszeichen gesetztes Feld einen echten Zeilenumbruch enthalten, was immer dann passiert, wenn eine Tabellenspalte eine mehrzeilige Adresse, eine Notiz oder einen Kommentar enthält. Der Parser bricht das Lesen eines Feldes nicht beim ersten Zeilenumbruch ab, sondern liest weiter, Zeilenumbrüche eingeschlossen, bis er auf das schließende Anführungszeichen trifft. Eine über zwei physische Zeilen exportierte Kundenadresse landet dadurch in JSON als ein einziger String-Wert mit einem eingebetteten Zeilenumbruch, statt mitten durchgeschnitten zu werden oder in die nächste Zeile überzulaufen.

Genau an dieser Stelle scheitern Umwandlungen, die mit einem schnellen regulären Ausdruck oder einem simplen Komma-Split gebastelt wurden. Dieser Parser existiert genau deshalb, damit diese Fälle nicht von Hand behandelt werden müssen.

Kopfzeilen und doppelte Spaltennamen

Ist "Erste Zeile als Kopfzeile" aktiviert, liefert die erste Zeile Ihrer eingefügten Daten den Schlüsselnamen für jedes Feld in jedem folgenden Objekt. Eine Kopfzeile wie name,email,alter bedeutet, dass jedes Ausgabeobjekt exakt diese drei Schlüssel in dieser Reihenfolge trägt. Deaktivieren Sie die Option bei CSV-Daten ganz ohne Kopfzeile, etwa einem rohen Datenbank-Export oder einer Logdatei, und das Werkzeug greift stattdessen auf generische Schlüssel zurück, col1, col2, col3 und so weiter, nummeriert nach Spaltenposition, sodass nichts stillschweigend verloren geht.

Doppelte Kopfzeilennamen verdienen besondere Aufmerksamkeit, weil der Fehler lautlos passiert statt eine Fehlermeldung auszulösen. Ein JSON-Objekt kann pro Schlüssel nur einen einzigen Wert halten, eine Kopfzeile wie name,telefon,telefon, etwa weil eine Tabelle separate Spalten für "Diensttelefon" und "Mobiltelefon" hatte und beide schlicht "telefon" genannt wurden, führt dazu, dass der zweite Telefonwert den ersten bei der Umwandlung überschreibt. Das ausgegebene JSON ist vollkommen gültig, es enthält nur leise eine Telefonnummer statt zwei, ohne jede Warnung, dass Daten verloren gegangen sind. Die Lösung liegt allein auf der Eingabeseite: Benennen Sie doppelte Spalten vor dem Einfügen um, etwa in telefon_dienst und telefon_mobil, damit jeder Schlüssel in der Kopfzeile bereits vor der Umwandlung eindeutig ist.

Typerkennung: Zahlen, Booleans und das Problem mit der führenden Null

CSV kennt keine Datentypen. Jede einzelne Zelle, ob sie einen Namen, ein Alter, einen Preis oder einen Wahrheitswert enthält, ist reiner Text, und die Checkbox "Zahlen erkennen" entscheidet, wie viel von diesem Text zu einem echten JSON-Typ befördert wird statt als String stehen zu bleiben. Ist die Option aktiviert, wird jedes Feld, das eine numerische Prüfung besteht, mit JavaScripts Number() umgewandelt, sodass "alter": "30" in der CSV zu "alter": 30 im JSON wird, bereit für Rechenoperationen oder Vergleiche, ohne dass Ihr eigener Code noch einen Umwandlungsschritt braucht.

Diese Bequemlichkeit hat einen echten Preis für Werte, die nur numerisch aussehen. Ein Artikelcode wie "007", eine Kontonummer wie "0042" oder eine Postleitzahl wie "01067", die PLZ von Dresden, bestehen alle die numerische Prüfung und werden zu 7, 42 beziehungsweise 1067, wobei jeweils genau die führende Null verloren geht, die den Wert erst bedeutungsvoll gemacht hat. Eine Postleitzahl ist eine Kennung, keine Menge, und sobald sie zur Zahl 1067 geworden ist, lässt sie sich nicht mehr von der Postleitzahl 10670 mit einer angehängten Ziffer unterscheiden. Enthalten Ihre Daten IDs, Codes oder Postleitzahlen neben echten numerischen Feldern, deaktivieren Sie "Zahlen erkennen" vor der Umwandlung und behalten Sie alles als String, oder wandeln Sie zweimal um und korrigieren Sie die Kennungsfelder anschließend von Hand.

Zwei dieser Zeilen sind leicht zu übersehen: Die Umwandlung von Booleans und die Behandlung leerer Zellen laufen unabhängig von der Checkbox "Zahlen erkennen" ab. Eine Zelle mit dem Text true oder false, unabhängig von Groß- und Kleinschreibung, wird immer zu einem echten JSON-Boolean, und eine wirklich leere Zelle wird immer zu null statt zu einem leeren String "". Das spielt eine Rolle, wenn Code, der die Ausgabe liest, gezielt mit === null prüft oder erwartet, dass jeder Wert eines bestimmten Schlüssels denselben JavaScript-Typ hat: Eine Spalte, die gelegentlich leer ist, erzeugt über das Array hinweg eine Mischung aus Strings und null-Werten statt durchgehend leerer Strings.

UTF-8 gegen Windows-1252: kaputte Umlaute aus Excel reparieren

Kodierungsfehler gehören zu den verwirrendsten Bugs überhaupt, weil die Datei in dem Programm, das sie erzeugt hat, vollkommen normal aussieht und erst irgendwo weiter unten in der Kette kaputtgeht. Der klassische Fall: Ein Namensfeld mit "München" oder "Grüße" wird aus Excel exportiert, in diesen oder einen anderen UTF-8-fähigen Konverter eingefügt, und kommt als München oder Grüße heraus statt als das Original. Diese doppelt kodierte Verstümmelung heißt Mojibake und hat eine konkrete Ursache: Die Datei wurde mit einer 8-Bit-Windows-Codepage gespeichert, meist Windows-1252, in der "ü" ein einzelnes Byte ist, wird aber anschließend als UTF-8 gelesen, wo dasselbe Zeichen zwei Bytes belegt, und jedes dieser beiden Bytes wird fälschlich als eigenständiges Zeichen interpretiert.

Die Lösung liegt im Speichern-unter-Dialog von Excel, nicht in diesem Werkzeug, denn sobald verstümmelter Text eingefügt wurde, sind die ursprünglichen Bytes bereits verloren. Unter Windows verwendet die schlichte Option "CSV (Trennzeichen-getrennt)" in der Dateitypliste auf vielen Installationen weiterhin die regionale Codepage des Systems, während "CSV UTF-8 (durch Trennzeichen getrennt)" die Datei ausdrücklich in UTF-8 schreibt, genau dem, was Browser und dieser Konverter erwarten. Erhalten Sie regelmäßig CSV-Dateien mit verstümmelten Umlauten von einer Kollegin oder einem Kunden, löst die Bitte um einen erneuten Export mit der UTF-8-Option, oder das Öffnen der Datei in einem reinen Texteditor mit anschließendem Speichern in UTF-8, das Problem an der Quelle statt es nachträglich flicken zu müssen.

Byte-Order-Mark und leere Schlusszeilen

Zwei kleinere Kodierungsartefakte lohnen sich zu kennen. Excel stellt einer UTF-8-CSV-Datei häufig eine Byte-Order-Mark voran, eine unsichtbare UTF-8-Signatur, die bei falscher Interpretation manchmal als  sichtbar wird und eigentlich anderen Programmen helfen soll, die Kodierung automatisch zu erkennen, gelegentlich aber als überzähliges Zeichen am ersten Spaltennamen klebt, wenn ein Werkzeug sie nicht entfernt. Tabellenexporte enden zudem häufig mit einer leeren Zeile nach dem letzten echten Datensatz. Dieser Konverter filtert jede Zeile heraus, in der jede Zelle leer ist, bevor das JSON-Array aufgebaut wird, sodass ein abschließender Zeilenumbruch am Dateiende kein überzähliges leeres Objekt am Ende Ihrer Ausgabe erzeugt.

Warum dieser Konverter vollständig im Browser läuft

Viele "CSV in JSON umwandeln"-Werkzeuge im Netz laden im Hintergrund alles, was Sie einfügen, still auf einen Server hoch, verarbeiten es dort und schicken das Ergebnis zurück. Dieser Umweg bleibt im normalen Betrieb unsichtbar, bedeutet aber, dass Ihre Daten zumindest für einen Moment auf einem fremden Rechner lagen. Für einen öffentlichen Beispieldatensatz spielt das keine Rolle. Für eine Gehaltsabrechnung, eine Kundenliste, eine Lieferantenpreisliste oder alles, was einer Geheimhaltungsvereinbarung unterliegt, ist es ein echtes Risiko, das die wenigsten Menschen überhaupt in Betracht ziehen.

Dieser Konverter geht diesen Umweg nicht. Die Parsing-Logik ist reines JavaScript, das mit der Seite ausgeliefert wird und vollständig in Ihrem eigenen Browser-Tab läuft, sobald Sie auf "In JSON umwandeln" klicken. Öffnen Sie während der Nutzung den Netzwerk-Tab Ihres Browsers, finden Sie keine einzige Anfrage, die Ihre CSV-Daten irgendwohin überträgt. Das hat neben dem Datenschutz einen praktischen Nebeneffekt: Es gibt kein serverseitiges Ratenlimit, keine von einer API vorgegebene Dateigrößenbeschränkung und keine Warteschlange, weil Ihr eigenes Gerät die gesamte Arbeit übernimmt statt eines gemeinsam genutzten Backends.

Was das für vertrauliche Exporte bedeutet

Wandeln Sie Personaldaten, Gehaltsabrechnungen, Kundendaten, Finanzzahlen oder unveröffentlichte Produktinformationen um, nimmt ein rein clientseitiges Werkzeug dieses Risiko vollständig aus der Gleichung, statt Sie auf eine ungelesene Datenschutzerklärung vertrauen zu lassen. Gerade bei personenbezogenen Daten, die unter die DSGVO fallen, ist das mehr als nur Bequemlichkeit: Wenn nichts das eigene Gerät verlässt, entfällt auch die Frage, wo und wie lange ein Drittanbieter diese Daten zwischenspeichert. Es ist dieselbe Überlegung, die Entwickler dazu bringt, einen Code-Formatierer lokal statt in einem beliebigen Webformular laufen zu lassen: Das sicherste Werkzeug ist das, das niemals die Gelegenheit hatte, etwas nach außen dringen zu lassen.

Typische Einsatzbereiche für diesen CSV-zu-JSON-Konverter

Dieselbe Umwandlung taucht in ganz unterschiedlichen Aufgaben auf. Ein paar Muster wiederholen sich dabei ständig.

Frontend-Prototyping ohne Backend

Frontend-Entwicklerinnen, die eine Komponente, eine Tabelle oder ein Dashboard-Mockup bauen, brauchen oft realistische Beispieldaten, bevor überhaupt eine echte API existiert. Eine Tabelle mit Beispielzeilen zu exportieren und hier umzuwandeln liefert ein einsatzbereites JSON-Array, das sich direkt in eine Mock-Datendatei oder eine lokale Fixture einfügen lässt.

Import in eine Dokumentendatenbank oder NoSQL-Store

Datenbanken wie MongoDB speichern Dokumente als JSON-ähnliche Objekte statt als Tabellen, weshalb ein Datensatz, der ursprünglich als Tabellenexport begann, oft erst zu einem JSON-Array werden muss, bevor er sich mit einem Werkzeug wie mongoimport importieren lässt. Die Umwandlung hier ist meist der schnellste Weg von einer Tabelle zu einer importierbaren Datei.

API-Tests und Mock-Payloads

QA-Ingenieure und Backend-Entwickler, die Testfälle in Werkzeugen wie Postman oder Insomnia bauen, starten häufig mit einer Tabelle aus Beispieleingaben, eine Zeile pro Testfall, und brauchen genau diese Daten als JSON-Array aus Request-Bodys. Einmal hier umzuwandeln hält die Tabelle als Quelle der Wahrheit, während gleichzeitig genau die JSON-Struktur entsteht, die ein Testrunner erwartet.

Datenmigration und einmalige Skripte

Die Migration von Daten zwischen Systemen, ein alter CRM-Export in das Importformat einer neuen Plattform oder ein Legacy-Datenbank-Dump in eine moderne Anwendung, läuft häufig über ein Skript, das JSON liest. Den rohen Export zuerst hier umzuwandeln erspart es, innerhalb dieses Skripts überhaupt einen eigenen CSV-Parsing-Schritt zu schreiben.

Konfiguration und Inhalte aus Tabellenkalkulationen

Nicht-technische Teammitglieder pflegen eine Liste oft viel lieber in Google Sheets als direkt in einer JSON-Datei, sei es eine Liste von FAQ-Einträgen, Produktkategorien oder Feature-Flags. Deren Tabelle bei jeder Aktualisierung hier umzuwandeln hält die JSON-Datei mit dem synchron, was zuletzt bearbeitet wurde, ohne dass diese Person einen Texteditor anfassen muss.

Tipps für saubere Umwandlungen und häufige Fallstricke

• Prüfen Sie das erkannte Trennzeichen bei kurzen Dateien. Die automatische Erkennung untersucht die ersten fünf Zeilen und hat bei einer Datei mit nur einer oder zwei Zeilen entsprechend wenig Material. Wirkt die Ausgabe bei einer winzigen Beispieldatei falsch, stellen Sie das Trennzeichen lieber manuell ein, statt der automatischen Erkennung zu vertrauen.
• Entscheiden Sie sich vor der Umwandlung für "Zahlen erkennen", nicht danach. Sobald IDs, Codes oder Postleitzahlen ihre führenden Nullen an die Zahlenumwandlung verloren haben, ist diese Information aus der Ausgabe verschwunden. Prüfen Sie Ihre Spalten zuerst auf kennungsartige Felder und lassen Sie die Option deaktiviert, wenn auch nur eine davon gefährdet aussieht.
• Achten Sie auf doppelte Kopfzeilennamen. Zwei Spalten mit derselben Überschrift verschmelzen in jedem Ausgabeobjekt lautlos zu einem einzigen Schlüssel. Benennen Sie Duplikate vor dem Einfügen um, denn das Werkzeug kann nicht erraten, welches Duplikat Sie eigentlich behalten wollten.
• Denken Sie daran, dass Felder getrimmt werden. Führende und abschließende Leerzeichen um jedes Feld werden beim Parsen entfernt, ein Wert wie " Berlin " kommt also als "Berlin" heraus. Das ist meistens erwünscht, bedeutet aber, dass leerzeichenempfindliche Daten, etwa ein Code, der absichtlich mit einem Leerzeichen beginnt, den Umweg nicht übersteht.
• Exportieren Sie bei verstümmelten Zeichen erneut aus Excel als UTF-8. Mojibake lässt sich fast immer auf eine Kodierungsinkonsistenz beim Export zurückführen, nicht auf einen Fehler beim Einfügen oder im Parser, und die sauberste Lösung ist eine andere Speichern-unter-Option in der Ausgangstabelle statt eine manuelle Nachbearbeitung.
• Nutzen Sie die Einrückungsoption passend zum nächsten Schritt. Wählen Sie 2 oder 4 Leerzeichen für Ausgaben, die Sie lesen oder in die Versionskontrolle einchecken wollen, oder Minifiziert, wenn das JSON direkt in eine API-Anfrage oder ein Skript wandert, bei dem die Dateigröße wichtiger ist als die Lesbarkeit.

Die meisten Überraschungen bei der Umwandlung lassen sich auf eines dieser fünf Dinge zurückführen: das falsche Trennzeichen, eine unerwünschte Zahlenumwandlung, eine doppelte Kopfzeile, ein Kodierungsproblem oder getrimmte Leerzeichen. Keines davon ist ein Fehler im Parser, es sind Eigenschaften der Ausgangsdaten, die einen kurzen Blick wert sind, bevor Sie auf Umwandeln klicken.

Häufig gestellte Fragen

Verwandte Entwickler-Werkzeuge

🔒 100% Clientseitige Privatsphäre

Die gesamte CSV-Verarbeitung und JSON-Erzeugung erfolgt <strong>vollständig in Ihrem Browser</strong>. Es werden keine Daten auf einen Server hochgeladen. Ihre Daten bleiben jederzeit auf Ihrem Gerät.