Praca z tekstem JSON zwykle sprowadza się do trzech różnych zadań: uczynienia go czytelnym, uczynienia go kompaktowym albo sprawdzenia, czy w ogóle jest poprawny. To trzy osobne operacje, choć często są łączone w jednym narzędziu.
Formatowanie (pretty-print)
Formatowanie dodaje wcięcia, podziały wierszy i spacje wokół znaków interpunkcyjnych, dzięki czemu strukturę JSON łatwo odczytać wzrokiem. To zmiana czysto kosmetyczna — nie wpływa na dane, tylko na ich wizualną prezentację.
Minimalizacja (minify)
Minimalizacja usuwa wszystkie zbędne spacje, podziały wierszy i wcięcia, pozostawiając tylko niezbędne znaki. Zmniejsza to rozmiar pliku, co ma znaczenie przy przesyłaniu danych przez sieć lub przechowywaniu dużych ilości danych — sama struktura danych się nie zmienia.
Walidacja
Walidacja sprawdza, czy tekst jest składniowo poprawnym JSON-em. Typowe błędy, które wykrywa: zbędny przecinek przed nawiasem zamykającym, pojedyncze cudzysłowy zamiast podwójnych, klucze obiektu bez cudzysłowów, komentarze (których standard JSON w ogóle nie przewiduje) czy niezamknięte nawiasy. Poprawny JSON jest warunkiem koniecznym, aby formatowanie czy minimalizacja w ogóle zadziałały.
Kiedy co jest potrzebne
- Formatowanie — przy debugowaniu odpowiedzi API lub ręcznej edycji plików konfiguracyjnych.
- Minimalizacja — przed wysłaniem danych przez sieć lub osadzeniem w kodzie produkcyjnym.
- Walidacja — przy diagnozowaniu, dlaczego parser odmawia odczytania pliku JSON.
Stare kodowanie Windows-1250 wciąż straszy w polskich plikach
Polskie znaki diakrytyczne (ą, ć, ę, ł, ń, ó, ś, ź, ż) w JSON-ie bez flagi typu ensure_ascii=False zamieniają się w sekwencje \uXXXX — na przykład "miasto": "Łódź" stanie się "miasto": "Łódź". To wciąż poprawny JSON, ale nieczytelny przy debugowaniu. Gorszy jest inny, starszy problem: część firmowych systemów w Polsce wciąż eksportuje pliki tekstowe w kodowaniu Windows-1250 lub ISO-8859-2 zamiast UTF-8, a JSON wymaga UTF-8 — wczytanie takiego pliku bez konwersji kodowania daje na wyjściu bełkot (mojibake) zamiast polskich liter, mimo że sama składnia JSON pozostaje formalnie poprawna.
JSON5 i JSONC to nie ten sam JSON
Niektóre środowiska (np. konfiguracje VS Code czy TypeScript) akceptują przecinki końcowe, komentarze i klucze bez cudzysłowów — to rozszerzenia JSON5 lub JSONC, a nie standardowy JSON (RFC 8259). Walidator ustawiony na ścisły JSON poprawnie odrzuci taki plik, mimo że edytor go „rozumie".