Konwerter JSON na YAML

Wklej poprawny JSON — obiekt, tablicę, skalar, odpowiedź API lub pełny manifest Kubernetes — a konwerter wygeneruje odpowiednik YAML w czasie rzeczywistym.

Konwersja odbywa się w całości w Twojej przeglądarce za pomocą natywnej funkcji JSON.parse do walidacji danych wejściowych (zgodnie z normą ECMA-404 / RFC 8259), a następnie przechodzi przez sparsowane drzewo, generując składnię YAML 1.2.2.

Wcięcia na 2 spacje są domyślne — to standard de facto w środowiskach Kubernetes, Ansible, GitHub Actions oraz Docker Compose. Przełącz na wcięcia 4-spacjowe, jeśli wymaga tego Twój kod.

Wynik jest gotowy do wklejenia do pliku `.yaml` lub przesłania potokiem do `kubectl apply -f -`. Prawy panel pokazuje na żywo liczbę bajtów i wierszy, dzięki czemu możesz sprawdzić rozmiar przed zatwierdzeniem.

Skonwertuj w trzech krokach:

• Krok 1: Wklej swój JSON do edytora. Konwerter weryfikuje dane w trakcie pisania — niepoprawny JSON pokazuje dokładnie błąd parsera wraz z wierszem i kolumną.
• Krok 2: Wynik YAML pojawia się na żywo w prawym panelu. Nie trzeba klikać żadnego przycisku; każde naciśnięcie klawisza odświeża widok.
• Krok 3: Kliknij Kopiuj (schowek) lub Pobierz (plik `.yaml`).

W przypadku automatycznych przepływów pracy ta sama logika jest udostępniana przez endpoint `/api/calculate` — wyślij do niego żądanie POST z JSON-em, a w ciele odpowiedzi otrzymasz YAML.

Bezpieczeństwo konwersji zwrotnej: skonwertuj YAML z powrotem do JSON za pomocą powiązanego konwertera YAML na JSON; model danych jest zachowany w całości (komentarze i kotwice są specyficzne dla YAML i nie przeżywają konwersji zwrotnej).

JSON i YAML reprezentują ten sam model danych — mapy (obiekty), sekwencje (tablice) oraz skalary (ciągi znaków/liczby/wartości logiczne/null) — ale przy użyciu zupełnie innej składni wizualnej.

JSON jest pełen nawiasów i cudzysłowów: każdy klucz ma `"`, każda mapa ma `{}`, każda tablica ma `[]`, a każdy separator jest jawny (`:` oraz `,`). YAML opiera się na wcięciach: zagnieżdżenie wynika z 2-spacjowego wcięcia, sekwencje używają przedrostka `- `, a większość ciągów znaków nie potrzebuje cudzysłowów.

JSON parsuje się 5–10 razy szybciej we wszystkich głównych środowiskach uruchomieniowych języków, jest całkowicie jednoznaczny i stanowi właściwy wybór dla interfejsów API, kolejek wiadomości, strumieni logów oraz formatów pamięci masowej.

YAML obsługuje komentarze (`#`), kotwice i aliasy do wielokrotnego użytku (`&name` / `*name`), strumienie wielodokumentowe (`---`) oraz jawne znaczniki typów (`!!str`, `!!int`) — zalety, które czynią go idealnym wyborem dla konfigurowanych w systemach kontroli wersji plików, rurociągów CI/CD, infrastruktury jako kodu oraz manifestów Kubernetes.

Wybierz JSON dla maszyn, YAML dla ludzi, a konwersji dokonuj na ich styku.

Głębokie zagnieżdżanie to obszar, w którym konwersja JSON na YAML pokazuje swoją wartość — ręczne śledzenie nawiasów i wcięć na poziomie 5+ jest podatne na błędy.

Konwerter rekurencyjnie przechodzi przez sparsowane drzewo JSON:

• Dla każdej mapy (obiektu) klucze są generowane w kolejności źródłowej za pomocą składni `klucz: wartość`; zagnieżdżone wartości mają dodatkowe wcięcie o 2 spacje.
• Dla każdej sekwencji (tablicy) elementy używają przedrostka `- `; zagnieżdżone obiekty pod znakiem `-` zaczynają się w tym samym wierszu co myślnik i dziedziczą kolejny poziom wcięć.

Mieszane struktury — tablice obiektów, obiekty zawierające tablice obiektów w sposób rekurencyjny — renderują się prawidłowo. Maksymalna głębokość jest ograniczona jedynie stosem wywołań przeglądarki (ok. 10 000+ ramek w nowoczesnych przeglądarkach, co znacznie przewyższa jakiekolwiek realne pliki konfiguracyjne).

Przetestuj za pomocą własnych danych testowych: sparsuj wynik YAML z powrotem do JSON i upewnij się, że struktury są identyczne.

Manifesty Kubernetes to najczęstszy przypadek użycia tego konwertera. Wiele narzędzi (kubectl, Lens, k9s, Helm) generuje JSON za pomocą flagi `-o json`; kanonicznym formatem źródłowym przechowywanym w Git jest jednak YAML.

Wklej wynik JSON polecenia `kubectl get deployment -o json`, a konwerter wygeneruje czysty manifest gotowy do zatwierdzenia. Hierarchie apiVersion, kind, metadata i spec zachowują dokładnie tę samą kolejność pól.

W przypadku wartości wykresów Helm wklej swoje wartości JSON i umieść YAML w pliku `values.yaml` — szablony Helm odbiorą go bez zmian. W przypadku nakładek Kustomize skonwertuj swój obiekt łatki i dodaj go do listy `patchesStrategicMerge`.

Przed zatwierdzeniem zweryfikuj wynik za pomocą polecenia `kubectl apply --dry-run=client -f file.yaml` — pozwoli to wykryć problemy na poziomie schematu, których sama walidacja składni YAML by nie wychwyciła.

Pliki Docker Compose to czysty format YAML zgodny ze specyfikacją Compose (compose-spec.io). Jeśli masz programowy wynik w formacie JSON — z generatora konfiguracji, poprzedniego eksportu Compose v2 lub skryptu szablonującego — przekonwertuj go tutaj i wklej do pliku `docker-compose.yaml`.

Główne klucze (`services`, `networks`, `volumes`, `configs`, `secrets`) oraz ich zagnieżdżone specyfikacje (image, ports, environment, depends_on, healthcheck) konwertują się prawidłowo.

Uważaj na porty: skrótowe ciągi znaków, takie jak `"8080:80"`, muszą pozostać w cudzysłowie w języku YAML, aby zapobiec interpretowaniu ich jako liczby w systemie sześćdziesiątkowym — konwerter obsługuje to automatycznie.

Przed uruchomieniem polecenia `docker compose up` sprawdź konfigurację za pomocą `docker compose config`; analizuje ono pliki, łączy wiele z nich i wyświetla gotową konfigurację dokładnie w takiej postaci, w jakiej uruchomi ją silnik.

Zasady dotyczące wcięć w języku YAML są surowe: 2 spacje na poziom (4 są również poprawne, ale rzadkie), tabulatory są zabronione, a klucze na tym samym poziomie muszą być idealnie wyrównane. Sekcje (`- item`) i mapy (`key: value`) mogą się swobodnie zagnieżdżać.

Ciągi wielowierszowe występują w dwóch wariantach: bloki dosłowne (`|`) zachowują każdy znak nowej linii; bloki zwinięte (`>`) łączą linie spacjami (w stylu akapitów).

Kotwice (`&name`) i alias (`*name`) pozwalają zdefiniować węzeł YAML raz i użyć go ponownie w innym miejscu — co jest powszechne w plikach Compose dla udostępnianych szablonów usług.

Jawne znaczniki typów (`!!str`, `!!int`, `!!bool`, `!!null`) zastępują automatyczne typowanie w języku YAML, gdy potrzebujesz ciągu znaków wyglądającego jak liczba lub odwrotnie.

Konwerter automatycznie obejmuje cudzysłowem niejednoznaczne ciągi znaków: `"yes"`, `"no"`, `"null"`, `"~"`, wartości wyglądające jak liczby, takie jak `"01234"`, oraz każdy ciąg zawierający znaki specjalne YAML (`:`, `#`, `-`, `&`, `*`, `!`, `|`, `>`, `'`, `"`, `%`, `@`).

Sześć błędów odpowiada za 95% uszkodzonych plików YAML w praktyce.

• (1) Tabulatory w dowolnym miejscu — nawet jeden znak tabulatora przerywa parsowanie. Skonfiguruj swój edytor tak, aby wstawiał spacje.
• (2) Niespójne wcięcia — klucz na tym samym poziomie przesunięty o jedną kolumnę powoduje błąd parsowania.
• (3) Brak spacji po `:` — `key:value` jest niepoprawne; `key: value` jest poprawne.
• (4) Nieujednoznacznione ciągi znaków wyglądające jak wartości logiczne (`yes`, `no`, `on`, `off`) — w YAML 1.1 (starsze parsery) są one przekształcane na wartości prawda/fałsz. YAML 1.2 ograniczył wartości logiczne wyłącznie do `true`/`false`, ale ostrożnościowe używanie cudzysłowów nadal jest zalecane.
• (5) Ciągi liczbowe bez cudzysłowów — `01234` staje się liczbą całkowitą 1234, tracąc wiodące zero.
• (6) Brak spacji po `-` — `-item` to ciąg znaków zaczynający się od myślnika; `- item` to element sekwencji.

Sprawdzaj poprawność za pomocą narzędzia `yamllint`, rozszerzenia YAML w programie VS Code lub walidatorów dedykowanych dla danej technologii (`kubectl --dry-run`, `docker compose config`, `ansible-playbook --syntax-check`).

Przepisy pracy z API korzystają z konwersji JSON na YAML w dwóch miejscach.

Po pierwsze, specyfikacje OpenAPI 3.x są powszechnie tworzone w języku YAML (są czytelniejsze dla drzew ścieżek i parametrów), ale eksportowane jako JSON na potrzeby narzędzi — możesz konwertować w dowolnym kierunku w zależności od potrzeb procesu edycji. Konwerter zachowuje wymagane pola, definicje schematów, wskaźniki $ref oraz przykładowe treści.

Po drugie, dokumentując API, możesz wkleić przykładową odpowiedź w formacie JSON i zaprezentować wersję YAML w dokumentacji — czytelnikom łatwiej jest wtedy przeglądać głęboko zagnieżdżone ciała odpowiedzi.

Na potrzeby integracji ze Swagger UI obsługiwane są zarówno pliki `swagger.yaml`, jak i `swagger.json`; wiele zespołów przechowuje format YAML w systemie kontroli wersji, a format JSON generuje w czasie kompilacji. Bezpieczeństwo konwersji w obie strony jest zachowane dla specyfikacji OpenAPI, ponieważ nie używają one komentarzy ani kotwic w swojej kanonicznej formie.

Prawie każda nowoczesna platforma CI/CD używa języka YAML do definiowania potoków:

• GitHub Actions (`.github/workflows/*.yaml`)
• GitLab CI (`.gitlab-ci.yml`)
• CircleCI (`.circleci/config.yml`)
• Travis (`.travis.yml`)
• Drone
• Concourse
• Argo Workflows
• Tekton

Gdy masz konfigurację w formacie JSON — pochodzącą z generatora, poprzedniego eksportu z systemu kontroli wersji lub programowego kreatora — wklej ją tutaj i wygeneruj YAML.

Playbooki Ansible opierają się w dużej mierze na strukturze listy zadań w formacie YAML z wykorzystaniem kotwic dla powtarzających się bloków; konwerter generuje sekwencje w czytelny sposób, dzięki czemu możesz je wkleić pod kluczem `tasks:` bez konieczności dalszych edycji.

W przypadku GitHub Actions najtrudniejszą częścią są warunki `if:` oraz strategie macierzowe — zachowaj przekonwertowany YAML, a następnie dodaj komentarze wyjaśniające intencje (funkcja dostępna tylko w YAML, którą utracisz, wracając do JSON).

Pięć przypadków brzegowych powoduje awarię prostych konwerterów.

• (1) Komentarze: Format JSON ich nie posiada, YAML obsługuje `#`. Konwersja w obie strony JSON → YAML → JSON nie powoduje strat, ale cykl YAML → JSON → YAML usuwa każdy komentarz. Zachowaj YAML jako swoje źródło prawdy, gdy komentarze mają znaczenie.
• (2) Rzutowanie wartości logicznych: starsze parsery YAML 1.1 traktują `yes`/`no`/`on`/`off` jak wartości logiczne. Nowoczesne parsery (1.2.2) traktują w ten sposób wyłącznie `true`/`false`, jednak stosowanie cudzysłowów zapobiega niespodziankom.
• (3) Null: Wartość `null` w JSON mapuje się w YAML na `null`, `~` lub pustą wartość. Konwerter wypisuje `null` dla jasności; niektóre narzędzia wolą puste pole (`key:`), ale może to być niejednoznaczne w przypadku pustych ciągów znaków.
• (4) Ciągi liczbowe: `"01234"` (kod pocztowy w USA) traci wiodące zero, jeśli w YAML nie zostanie ujęty w cudzysłów — konwerter dodaje cudzysłów.
• (5) Liczby zmiennoprzecinkowe z zerami końcowymi: `1.50` po konwersji w obie strony staje się wartością `1.5`, ponieważ zarówno JSON, jak i YAML używają kanonicznej reprezentacji liczbowej. Jeśli zera końcowe mają znaczenie (waluty, ciągi wersji), serializuj je jako ciągi znaków.

Szybki przegląd mapowania typów:

• Obiekt JSON → mapa YAML (styl blokowy)
• Tablica JSON → sekwencja YAML (elementy poprzedzone `-`)
• Ciąg znaków JSON → ciąg znaków YAML (automatycznie w cudzysłowie, gdy jest niejednoznaczny)
• Liczba JSON → skalar YAML o tej samej wartości liczbowej
• Wartość true/false JSON → true/false YAML
• Wartość null JSON → null YAML

Wybór stylu:

• preferuj styl blokowy (wielowierszowy, z wcięciami) ze względu na czytelność zamiast stylu przepływowego (`{key: value, ...}` w stylu kompaktowym JSON)
• zawsze używaj wcięć o szerokości 2 spacji
• generuj klucze w kolejności ich występowania w źródle (zgodnie z zachowaniem formatu JSON)

Porady dotyczące konwersji zwrotnej:

• (1) Cykl JSON → YAML → JSON przebiega bez strat danych.
• (2) Konwersja YAML → JSON powoduje usunięcie komentarzy, kotwic (są rozwijane), jawnych znaczników oraz strumieni wielodokumentowych.
• (3) Zawsze obejmuj cudzysłowem ciągi znaków wyglądające jak wartości logiczne, null lub liczby.
• (4) Przetestuj swój wynik za pomocą narzędzia, które będzie go przetwarzać (kubectl, docker compose, ansible-playbook) — mają one surowszą walidację niż ogólne parsery YAML.
• (5) Przechowuj obie wersje w systemie kontroli wersji, jeśli Twój zespół używa obu formatów; traktuj jeden z nich jako kanoniczny (zazwyczaj YAML dla konfiguracji, JSON dla API) i generuj drugi podczas kompilacji.