.env-Parser & -Validator

Fügen Sie eine .env-Datei ein — oder ziehen Sie sie auf das Feld — und erhalten Sie sie geparst, geprüft und erklärt zurück: jeden Schlüssel in einer Tabelle mit maskiertem Wert, jedes Problem mit seiner Zeilennummer aufgelistet. Doppelte Schlüssel, ungültige Namen, Zeilen, die gar keine Zuweisungen sind, leere Werte, die stillschweigend Standardwerte überschreiben. Es läuft vollständig in Ihrem Browser, und die Datei wird niemals hochgeladen, denn eine Produktions-.env ist ein Bündel von Geheimnissen und sollte wie eines behandelt werden.

Was geprüft wird — und warum

Das .env-Format ist eine Konvention, kein Standard, und deshalb verrotten Dateien still. Jeder Loader ist sich bei KEY=VALUE einig und bei allem anderen uneinig: ob export -Präfixe entfernt werden, ob Anführungszeichen beachtet werden, ob ein Inline-Kommentar einen Wert beendet und — am gefährlichsten — welche von zwei Definitionen desselben Schlüssels gewinnt. Dieser Validator wendet die Regeln des kleinsten gemeinsamen Nenners an und meldet die Stellen, an denen Loader auseinandergehen: ein Schlüssel, der zweimal definiert ist, mit beiden Zeilennummern, ein Name, den keine Shell akzeptieren würde, ein Anführungszeichen, das sich öffnet und nie schließt, eine Zeile ganz ohne Gleichheitszeichen. Leere Werte werden markiert statt als Fehler gewertet, denn KEY= ist legal — aber es überschreibt jeden Anwendungs-Standardwert mit einer leeren Zeichenkette, und das ist der häufigste Grund dafür, dass ein Dienst auf einer Maschine läuft und auf einer anderen nicht.

Das Datenschutz-Design ist das Feature. Eine Produktions-.env konzentriert Datenbankpasswörter, API-Schlüssel und Sitzungsgeheimnisse in einer kleinen Datei, und der natürliche Debugging-Schritt — sie irgendwo einzufügen und um Hilfe zu bitten — ist zugleich das Leck. KI-Chats, Issue-Tracker und Teamkanäle behalten Kopien, oft durchsuchbar, oft für immer. Deshalb folgt dieses Tool derselben Regel wie der Log-Parser und der Zertifikat-Generator: Die sensible Eingabe verlässt den Browser nie, Werte werden auf dem Bildschirm maskiert, und die einzigen Exporte sind Dateien, die Sie bewusst herunterladen. Der Begleitartikel Env-Dateien sind der Ort, an dem Geheimnisse lecken behandelt die Hygiene rund um die Datei selbst — was hineingehört, was nicht, und was zu tun ist, wenn eine entwischt.

Häufig gestellte Fragen

Ist es sicher, hier eine Produktions-.env einzufügen?

Ja — genau das ist der Zweck dieses Tools. Das Parsen läuft vollständig in Ihrem Browser: kein Upload, keine Server-Rundreise, und nichts, was Sie einfügen, wird irgendwohin übertragen oder gespeichert. Werte werden auf dem Bildschirm standardmäßig maskiert, sodass auch eine Bildschirmfreigabe oder ein Screenshot sie nicht leckt. Dasselbe gilt nicht für das Einfügen einer .env in einen KI-Chat, ein Ticket oder eine Teamnachricht — all diese behalten Kopien; der Artikel über Env-Dateien und leckende Geheimnisse erklärt die sichereren Gewohnheiten.

Warum ist ein doppelter Schlüssel wichtig, wenn ohnehin der letzte gewinnt?

Weil der Mensch, der die Datei bearbeitet, nicht weiß, welcher gewinnt. Er ändert den Wert in Zeile 4, deployt erneut und sieht zu, wie nichts passiert — der Loader hat still Zeile 41 verwendet. Schlimmer noch: Manche Frameworks nehmen die erste Definition, manche die letzte, sodass sich dieselbe Datei in einem Stack unterschiedlich verhält. Ein Schlüssel, eine Zeile, ein Wert: Der Validator listet jedes Duplikat mit beiden Zeilennummern auf, damit die tote Zeile gelöscht werden kann.

Meine App liest eine Variable, die nicht in der .env steht. Wie finde ich die?

Fügen Sie Ihren Code oder Ihre Konfiguration in das Verwendungsfeld ein. Der Parser extrahiert jeden referenzierten Namen — process.env.X, process.env[’X’], import.meta.env.X, ${X} und $X — und meldet beide Richtungen: Namen, die der Code referenziert, die die Datei aber nie definiert (diese werden zur Laufzeit zu undefined, meist im ungünstigsten Moment), und Schlüssel, die die Datei definiert, die aber nichts referenziert (tote Konfiguration, die überraschend oft noch lebendige Geheimnisse enthält).

Was gilt als ungültiger Schlüssel?

Alles, was nicht ein Buchstabe oder Unterstrich ist, gefolgt von Buchstaben, Ziffern und Unterstrichen. Schlüssel, die mit einer Ziffer beginnen, Bindestriche oder Punkte enthalten oder überflüssige Leerzeichen tragen, werden von vielen Loadern und Shells verworfen oder verstümmelt — eine Datei, die in bash sauber lädt, kann in einem Node-Loader genau daran scheitern. Der Validator markiert sie mit der Zeilennummer; die Eintragstabelle zeigt die Zeile trotzdem, damit Sie sehen, was verloren ginge.

Enthalten die Exporte die echten Werte?

Ja. Die JSON- und YAML-Downloads und das kopierte JSON sind die echte Konfiguration — die Maskierung ist ein Anzeigeschutz, keine Schwärzung Ihrer eigenen Daten. Behandeln Sie exportierte Dateien genau wie die .env selbst: niemals in ein öffentliches Repository committen, niemals an ein Ticket anhängen. Wenn Sie eine teilbare, sichere Version brauchen, teilen Sie den maskierten Screenshot oder die Schlüsselliste.