Konwerter JSON ↔ YAML

Czym jest to narzędzie?

YAML to preferowany format dla większości nowoczesnych plików konfiguracyjnych — manifestów Kubernetes, Docker Compose, pipeline'ów GitHub Actions i GitLab CI, playbooków Ansible — ponieważ jest bardziej czytelny niż JSON dla osób ręcznie edytujących pliki: nie trzeba ujmować w cudzysłów większości kluczy, nie ma przecinków na końcu, którymi łatwo się pomylić, a komentarze są obsługiwane. JSON z kolei jest tym, co większość API i języków programowania natywnie generuje i przyjmuje.

To narzędzie łączy oba formaty za pomocą js-yaml, szeroko stosowanej implementacji specyfikacji YAML w JavaScripcie, dzięki czemu parsowanie i generowanie odbywa się według tych samych reguł, jakie zastosowałoby narzędzie obsługujące YAML, takie jak `kubectl` czy runner CI.

Konwersja JSON na YAML zamienia obiekty w wcięte bloki klucz: wartość, a tablice w elementy listy poprzedzone znakiem `-`. Konwersja YAML na JSON działa odwrotnie, a dodatkowo rozwiązuje specyficzne dla YAML skróty typów (takie jak niecytowane `true`, `null` czy liczby) na ich właściwe typy JSON.

Dlaczego warto go używać?

• Dwukierunkowość — konwertuj JSON na YAML lub YAML na JSON z jednego ekranu.
• Parsowanie i generowanie oparte na standardach dzięki js-yaml, dzięki czemu wynik odpowiada temu, czego oczekują prawdziwe narzędzia YAML (Kubernetes, systemy CI, Ansible).
• Obsługuje zagnieżdżone obiekty i tablice na dowolnej głębokości, konwertując między opartą na wcięciach strukturą YAML a nawiasami klamrowymi i kwadratowymi JSON-a.
• Poprawnie interpretuje skróty typów YAML — niecytowane wartości true/false, null i liczbowe stają się właściwymi typami JSON zamiast ciągów znaków.
• Kopiuj do schowka lub pobierz jako plik .json albo .yaml.
• 100% po stronie klienta — nic, co wkleisz, nigdzie nie jest wysyłane.

Jak używać

1. Wybierz kierunek: „JSON → YAML” lub „YAML → JSON”.
2. Wklej dane do pola wejściowego.
3. Kliknij „Konwertuj”.
4. Sprawdź wynik, a następnie skopiuj go lub kliknij „Pobierz”, aby zapisać plik.

Przykład

Wejście

{"name":"Alice","roles":["admin","editor"],"active":true}

Wynik

name: Alice
roles:
  - admin
  - editor
active: true

Zwróć uwagę, jak tablica zamienia się w listę elementów z myślnikiem pod „roles”, a wartość logiczna pozostaje niecytowanym true zamiast stać się ciągiem znaków "true".

Praktyczne wskazówki

• Pisanie manifestu Kubernetes lub workflow GitHub Actions: naszkicuj strukturę jako JSON (wiele edytorów i narzędzi AI generuje JSON bardziej niezawodnie), a następnie przekonwertuj do YAML dla ostatecznego pliku.
• Debugowanie źle działającej konfiguracji YAML: przekonwertuj ją na JSON, aby dokładnie zobaczyć, które wartości są ciągami znaków, liczbami czy wartościami logicznymi — elastyczna składnia YAML może ukrywać niezgodności typów, które w JSON są oczywiste.
• Jeśli twój JSON zawiera klucze ze znakami specjalnymi lub zaczynające się od cyfry, js-yaml automatycznie ujmie je w cudzysłów w wyjściowym YAML, aby poprawnie sparsowały się z powrotem.

Dlaczego wymuszanie typów to najtrudniejsza część YAML

Największa zaleta YAML względem JSON pod względem użyteczności — brak konieczności ujmowania większości wartości w cudzysłów — jest jednocześnie największym źródłem subtelnych błędów. Klasycznym przykładem jest „problem Norwegii”: w YAML 1.1 (używanym przez wiele starszych parserów) niecytowana wartość `no` jest interpretowana jako wartość logiczna `false`, a nie ciąg znaków „no”, co w realnych przypadkach psuło konfiguracje zawierające kod kraju Norwegii. To narzędzie przestrzega specyfikacji YAML 1.2, która zawęziła zbiór niecytowanych wartości traktowanych jako logiczne do samych `true` i `false` (oraz ich wariantów wielkości liter), zmniejszając — choć nie eliminując całkowicie — tę klasę niespodzianek. W razie wątpliwości co do tego, jak wartość zostanie stypizowana, najbezpieczniejszym wyborem jest jawne ujęcie jej w cudzysłów w YAML.

Najczęściej zadawane pytania