Skip to content

Konwerter JSON na YAML

Wklej JSON, uzyskaj YAML natychmiast. Konwersja na żywo w przeglądarce. Obsługa K8s i Compose, wcięcia 2/4 spacje, bezpieczne cytowanie Norway. 100% prywatnie.

Bez śledzenia Działa w przeglądarce Bezpłatne
Opcje · 2 spacje · auto · blokowy
Wcięcie
Styl
0 znaków
YAML Wynik
0 linii
Zweryfikowano pod kątem zgodności z RFC 8259, wynikowego pliku zgodnego ze specyfikacją YAML 1.2 oraz poprawności obsługi problemu Norway — Go Tools Engineering Team · May 4, 2026

Czym jest YAML i dlaczego konwertować z JSON?

YAML (YAML Ain't Markup Language) to czytelny dla człowieka format serializacji danych zaprojektowany do plików konfiguracyjnych, infrastruktury jako kodu i wszędzie tam, gdzie człowiek pisze dane, które maszyna będzie czytać. Składnia oparta na wcięciach nie wymaga nawiasów klamrowych ani kwadratowych, co sprawia, że złożone zagnieżdżone struktury są znacznie czytelniejsze niż w JSON. Kubernetes, Helm, Ansible, Docker Compose, GitHub Actions, CircleCI i praktycznie każde narzędzie cloud-native używa YAML jako głównego formatu konfiguracji. Konwersja JSON do YAML jest więc jednym z najczęstszych zadań w DevOps i programowaniu backendowym — otrzymujesz definicję zasobu z API w JSON i potrzebujesz manifestu YAML do zatwierdzenia w repozytorium kodu.

Narzędzie ma cztery ważne cechy wyróżniające na tle typowych konwerterów online:

**1. Problem Norway — automatyczne bezpieczne cytowanie.** Największym problemem przy konwersji JSON do YAML jest problem Norway w YAML. W YAML 1.1 (którego miliony produkcyjnych parserów nadal używają, w tym starsze wersje Kubernetes, PyYAML, Ansible i Ruby Psych) ciągi yes, no, on, off, y i n są parsowane jako wartości logiczne true/false. Problem ten zasłynął na przykładzie kodu kraju ISO dla Norwegii ("NO" → false) i spowodował rzeczywiste awarie produkcyjne w konfiguracjach Kubernetes. YAML 1.2 to naprawił, ale parsery mogą jeszcze nie być na wersji 1.2. Domyślny tryb Auto tego narzędzia używa biblioteki eemeli/yaml ze schematem YAML 1.1, więc automatycznie ujmuje w cudzysłowy wszelkie ciągi będące problemem Norway, gwarantując bezpieczną konwersję w obie strony przez parsery zarówno YAML 1.1, jak i 1.2. Więcej informacji znajdziesz w naszym artykule Problem Norway w YAML i różnice JSON-YAML.

**2. Zachowanie kolejności kluczy.** W odróżnieniu od niektórych konwerterów sortujących klucze alfabetycznie, narzędzie zachowuje oryginalną kolejność wstawiania kluczy z JSON — zgodnie z zachowaniem JSON.parse() we wszystkich nowoczesnych silnikach JavaScript. Ma to znaczenie dla manifestów Kubernetes (gdzie apiVersion i kind są oczekiwane na początku zgodnie z konwencją), specyfikacji OpenAPI (gdzie info pojawia się przed paths) i każdej konfiguracji, w której kolejność pól jest istotna dla czytelności lub diffów.

**3. Ostrzeżenie o precyzji dużych liczb.** Liczby JSON większe niż 2^53 - 1 (9007199254740991) nie mogą być dokładnie reprezentowane przez 64-bitową liczbę zmiennoprzecinkową IEEE 754 JavaScript. Gdy JSON.parse() odczytuje dużą liczbę całkowitą, taką jak pole resourceVersion Kubernetes (które jest 64-bitową liczbą całkowitą po stronie serwera), cicho ją obcina. Jest to podstawowe ograniczenie JavaScript w przeglądarce dotyczące wszystkich narzędzi JSON opartych na przeglądarce, w tym tego. Bezpiecznym obejściem jest upewnienie się, że duże liczby całkowite są przechowywane jako ciągi znaków w JSON przed konwersją. Narzędzie uczciwie dokumentuje to zachowanie w sekcji o typowym błędzie utraty precyzji liczb poniżej.

**4. 100% prywatność w przeglądarce.** Dane JSON — często zawierające klucze API, dane uwierzytelniające baz danych, wewnętrzne konfiguracje usług i produkcyjne sekrety — nigdy nie opuszczają przeglądarki. Żadne dane nie są wysyłane na serwer. Można to zweryfikować w zakładce Sieć przeglądarki. Narzędzie do konwersji w odwrotnym kierunku znajdziesz pod adresem Konwerter YAML na JSON, a jeśli chcesz zwalidować i upiększyć JSON przed konwersją, skorzystaj z naszego formatowania JSON.

Czytelność YAML dla człowieka wiąże się jednak z kompromisem: format ten ma więcej przypadków brzegowych parsowania niż JSON. Poza problemem Norway istnieją osobliwości ósemkowe (0777 jest parsowane jako 511 w YAML 1.1), składnia ciągów wieloliniowych (| dla literalnego, > dla złożonego), referencje kotwic i aliasów (&anchor i *alias) oraz obsługa wielu dokumentów (separator ---). JSON nie ma żadnych z tych złożoności — jest ścisłym, minimalnym formatem z tylko sześcioma typami danych. Do maszynowej wymiany danych JSON jest prawie zawsze lepszym wyborem. Do plików konfiguracyjnych edytowanych przez człowieka, gdzie czytelność i komentarze mają znaczenie, YAML wygrywa. Ten konwerter daje obie zalety: używasz JSON programistycznie, konwertujesz do YAML dla infrastruktury.

// Convert JSON to YAML in Node.js using the eemeli/yaml library
import { Document } from 'yaml';

const data = JSON.parse('{"apiVersion":"apps/v1","kind":"Deployment"}');

// version: '1.1' ensures Norway-problem strings (yes/no/on/off/y/n)
// are automatically quoted in the output for YAML 1.1 parser safety
const doc = new Document(data, { version: '1.1' });

const yamlString = doc.toString({
  indent: 2,
  lineWidth: 0,         // disable line wrapping
  defaultStringType: 'PLAIN',   // Auto mode: only quote when needed
});

console.log(yamlString);
// apiVersion: apps/v1
// kind: Deployment

Kluczowe funkcje

Konwersja na żywo

Wynik YAML aktualizuje się natychmiast podczas wpisywania lub wklejania JSON — bez potrzeby klikania przycisku Konwertuj. Duże dane wejściowe (>200 KB) automatycznie przełączają się na tryb ręczny, aby przeglądarka pozostała responsywna.

Wcięcie 2 lub 4 spacje

Przełączaj między wcięciem 2-spacjowym (standard dla Kubernetes, Docker Compose i GitHub Actions) a 4-spacjowym (konwencja Ansible). YAML zabrania tabulatorów — narzędzie zawsze używa spacji.

Automatyczne bezpieczne cytowanie (bezpieczne dla Norway)

Domyślny tryb Auto używa schematu YAML 1.1, by automatycznie ujmować w cudzysłowy ciągi takie jak "no", "yes", "on", "off", "y" i "n", które byłyby błędnie odczytywane jako wartości logiczne przez parsery YAML 1.1, zapobiegając błędnym konfiguracjom produkcyjnym.

Style blokowy i przepływowy

Styl blokowy tworzy wcięty, czytelny dla człowieka YAML idealny dla manifestów i plików konfiguracyjnych. Styl przepływowy tworzy zwarte, wbudowane YAML podobne do JSON — przydatne dla fragmentów dokumentacji lub narzędzi preferujących minimalne wyjście.

100% prywatność w przeglądarce

Cała konwersja odbywa się lokalnie w przeglądarce przy użyciu JavaScript. Dane JSON — w tym klucze API, dane uwierzytelniające i konfiguracje produkcyjne — nigdy nie są wysyłane na żaden serwer, nigdy nie są rejestrowane ani przechowywane.

Obsługa plików K8s, Compose i Terraform

Zoptymalizowane dla rzeczywistych zastosowań DevOps: manifesty Kubernetes, stosy Docker Compose, Helm chart values, przepływy pracy GitHub Actions, specyfikacje OpenAPI i plany JSON Terraform — z przykładami dla każdego przypadku.

Przykłady

Kubernetes Deployment

{"apiVersion":"apps/v1","kind":"Deployment","metadata":{"name":"my-app","namespace":"production","labels":{"app":"my-app","version":"1.0.0"}},"spec":{"replicas":3,"selector":{"matchLabels":{"app":"my-app"}},"template":{"metadata":{"labels":{"app":"my-app"}},"spec":{"containers":[{"name":"my-app","image":"my-app:1.0.0","ports":[{"containerPort":8080}],"resources":{"requests":{"memory":"64Mi","cpu":"250m"},"limits":{"memory":"128Mi","cpu":"500m"}}}]}}}}

Konwersja manifestu Kubernetes Deployment z formatu odpowiedzi JSON API do YAML gotowego do użycia z kubectl apply -f

Docker Compose

{"version":"3.9","services":{"web":{"image":"nginx:1.25-alpine","ports":["80:80","443:443"],"environment":{"NGINX_HOST":"example.com","NGINX_PORT":"80"},"depends_on":["db"],"restart":"unless-stopped"},"db":{"image":"postgres:16-alpine","environment":{"POSTGRES_DB":"mydb","POSTGRES_USER":"admin","POSTGRES_PASSWORD":"secret"},"volumes":["pgdata:/var/lib/postgresql/data"]}},"volumes":{"pgdata":{}}}

Konwersja definicji usług Docker Compose z JSON do formatu YAML wymaganego przez docker compose up

Przepływ pracy GitHub Actions

{"name":"CI","on":{"push":{"branches":["main"]},"pull_request":{"branches":["main"]}},"jobs":{"build":{"runs-on":"ubuntu-latest","steps":[{"uses":"actions/checkout@v4"},{"name":"Set up Node.js","uses":"actions/setup-node@v4","with":{"node-version":"20","cache":"pnpm"}},{"name":"Install dependencies","run":"pnpm install --frozen-lockfile"},{"name":"Run tests","run":"pnpm test"}]}}}

Konwersja definicji przepływu pracy CI GitHub Actions z JSON do YAML do zatwierdzenia w .github/workflows/

Specyfikacja OpenAPI

{"openapi":"3.0.3","info":{"title":"User API","version":"1.0.0","description":"Manage application users"},"paths":{"/users":{"get":{"summary":"List users","operationId":"listUsers","parameters":[{"name":"limit","in":"query","schema":{"type":"integer","default":20}}],"responses":{"200":{"description":"Success","content":{"application/json":{"schema":{"type":"array","items":{"$ref":"#/components/schemas/User"}}}}}}}},"/users/{id}":{"get":{"summary":"Get user","operationId":"getUser","parameters":[{"name":"id","in":"path","required":true,"schema":{"type":"string"}}],"responses":{"200":{"description":"Success"}}}}},"components":{"schemas":{"User":{"type":"object","properties":{"id":{"type":"string"},"name":{"type":"string"},"email":{"type":"string","format":"email"}}}}}}

Konwersja specyfikacji OpenAPI 3.0 z JSON do YAML — preferowanego formatu dla Swagger UI, Redoc i większości narzędzi API

package.json

{"name":"my-app","version":"1.0.0","description":"A sample Node.js application","private":true,"scripts":{"dev":"vite","build":"tsc && vite build","preview":"vite preview","test":"vitest","lint":"eslint . --ext .ts,.tsx"},"dependencies":{"react":"^18.3.0","react-dom":"^18.3.0"},"devDependencies":{"typescript":"^5.4.0","vite":"^5.2.0","vitest":"^1.5.0","eslint":"^8.57.0","@types/react":"^18.3.0"},"engines":{"node":">=20.0.0","pnpm":">=9.0.0"}}

Konwersja typowego pliku package.json dla Node.js do YAML — przydatne przy migracji konfiguracji projektu do narzędzi preferujących YAML

Plan JSON Terraform

{"format_version":"1.0","terraform_version":"1.7.4","variables":{"region":{"value":"us-east-1"}},"planned_values":{"root_module":{"resources":[{"address":"aws_s3_bucket.main","mode":"managed","type":"aws_s3_bucket","name":"main","values":{"bucket":"my-app-assets","force_destroy":false,"tags":{"Environment":"production","ManagedBy":"terraform"}}}]}},"resource_changes":[{"address":"aws_s3_bucket.main","mode":"managed","type":"aws_s3_bucket","name":"main","change":{"actions":["create"],"before":null,"after":{"bucket":"my-app-assets","force_destroy":false}}}]}

Konwersja wynikowego planu JSON Terraform do YAML na potrzeby przeglądu przez człowieka, ścieżek audytu GitOps i potoków CI/CD — funkcja pomijana przez większość konwerterów

Jak używać

  1. 1

    Wklej dane JSON

    Wprowadź lub wklej dane JSON do pola wejściowego powyżej. Możesz też kliknąć «Wczytaj przykład», aby wypróbować próbkę, np. Kubernetes Deployment, plik Docker Compose lub plan Terraform.

  2. 2

    Zobacz wynik YAML na żywo

    YAML pojawia się natychmiast w panelu wyjściowym. Dostosuj Opcje (wcięcie 2/4, cudzysłowy Auto/Podwójne/Pojedyncze, styl Blokowy/Przepływowy), aby spełnić wymagania docelowego narzędzia.

  3. 3

    Kopiuj lub pobierz

    Kliknij Kopiuj, aby przenieść YAML do schowka, lub Pobierz, aby zapisać go jako plik .yaml gotowy do kubectl apply, docker compose up lub innego narzędzia.

Typowe problemy przy konwersji

Przecinki kończące

JSON nie dopuszcza przecinka po ostatnim elemencie obiektu lub tablicy. Jest to niezwykle częste przy kopiowaniu z kodu JavaScript, który dopuszcza przecinki kończące. Usuń końcowy przecinek przed konwersją.

✗ Niepoprawne
{"name": "Alice", "role": "admin",}
✓ Poprawne
{"name": "Alice", "role": "admin"}

Apostrofy

JSON wymaga cudzysłowów podwójnych dla wszystkich wartości ciągów znaków i kluczy obiektów. Apostrofy są poprawne w JavaScript i Pythonie, ale są błędem składni w JSON.

✗ Niepoprawne
{'name': 'Alice', 'active': true}
✓ Poprawne
{"name": "Alice", "active": true}

Klucze bez cudzysłowów

Wszystkie klucze obiektów JSON muszą być ujęte w cudzysłowy podwójne. Klucze bez cudzysłowów są poprawne w literałach obiektów JavaScript, ale powodują błąd parsowania w ścisłym JSON.

✗ Niepoprawne
{name: "Alice", role: "admin"}
✓ Poprawne
{"name": "Alice", "role": "admin"}

Komentarze niedozwolone

Standardowy JSON nie obsługuje żadnego rodzaju komentarzy — ani //, ani /* */, ani #. Jeśli komentarze w konfiguracji są potrzebne, użyj YAML (który obsługuje komentarze #) lub JSONC (JSON with Comments, używany przez VS Code). Usuń wszystkie komentarze przed użyciem danych jako JSON.

✗ Niepoprawne
{"port": 8080 // HTTP port}
✓ Poprawne
{"port": 8080}

Problem Norway w YAML (obsługiwany automatycznie w trybie Auto)

W parserach YAML 1.1 (używanych przez Kubernetes, Ansible, PyYAML, Ruby Psych) ciągi yes, no, on, off, y i n są parsowane jako wartości logiczne true/false zamiast ciągów znaków. Tryb Auto tego narzędzia automatycznie ujmuje te wartości w cudzysłowy w wynikowym YAML, gwarantując bezpieczną konwersję w obie strony przez dowolny parser YAML 1.1 lub 1.2. Jeśli wybierzesz tryb Podwójne lub Pojedyncze, wszystkie ciągi będą jawnie ujęte w cudzysłowy, co również eliminuje problem — ale tryb Auto daje najbardziej naturalne wyjście.

✗ Niepoprawne
# JSON input: {"country": "no", "enabled": "yes"}
# YAML without quoting (dangerous):
country: no
enabled: yes
# YAML 1.1 parser reads: country=false, enabled=true
✓ Poprawne
# YAML with Auto quoting (safe):
country: 'no'
enabled: 'yes'
# YAML 1.1 parser reads: country="no", enabled="yes"

Utrata precyzji dużych liczb całkowitych

JavaScript może precyzyjnie reprezentować liczby całkowite tylko do 2^53 - 1 (9007199254740991). Liczby całkowite JSON większe niż ta wartość — takie jak pola resourceVersion Kubernetes (które są int64 po stronie serwera) — są cicho zaokrąglane podczas parsowania przez JSON.parse(). Obcięta liczba pojawia się następnie w wynikowym YAML. Jest to podstawowe ograniczenie JavaScript w przeglądarce dotyczące wszystkich narzędzi JSON opartych na przeglądarce. Bezpiecznym obejściem jest przechowywanie dużych liczb całkowitych jako ciągów znaków w JSON przed konwersją.

✗ Niepoprawne
// JSON input (resourceVersion is int64 on K8s server)
{"resourceVersion": 9007199254740993}
// JavaScript reads it as: 9007199254740992 (precision lost)
// YAML output will contain the wrong number
✓ Poprawne
// Store large integers as strings to preserve precision
{"resourceVersion": "9007199254740993"}
// YAML output: resourceVersion: '9007199254740993' (exact)

Typowe zastosowania

Manifesty Kubernetes
Konwersja odpowiedzi JSON z kubectl get -o json lub API Kubernetes do manifestów YAML dla przepływów pracy GitOps, nakładek Kustomize i wdrożeń kubectl apply -f.
Pliki Docker Compose
Przekształcanie wynikowego JSON docker inspect lub programowo generowanych konfiguracji usług w pliki docker-compose.yaml zgodne z docker compose up i wdrożeniami Docker Stack.
Helm chart values
Konwersja eksportów konfiguracji JSON do plików YAML values dla wdrożeń Helm chart, umożliwiająca wersjonowaną konfigurację infrastruktury z przejrzystą składnią YAML.
Przepływy pracy GitHub Actions
Programowe budowanie definicji przepływów pracy GitHub Actions w JSON i konwersja do formatu .github/workflows/*.yaml wymaganego przez runner GitHub Actions.
Specyfikacje OpenAPI
Konwersja specyfikacji OpenAPI/Swagger z formatu JSON zwracanego przez wiele frameworków (FastAPI, SpringDoc) do formatu YAML preferowanego przez Swagger UI, Redoc i narzędzia bramki API.
Migracja konfiguracji
Migracja konfiguracji aplikacji przechowywanych w JSON (appsettings.json, config.json) do formatu YAML dla narzędzi wymagających lub preferujących YAML, z możliwością dodawania komentarzy dokumentacyjnych.

Szczegóły techniczne

Parsowanie JSON zgodne z RFC 8259
Dane wejściowe JSON są parsowane przy użyciu natywnego JSON.parse() przeglądarki, który jest w pełni zgodny z RFC 8259. Zapewnia to dokładne komunikaty błędów składni (z informacją o pozycji — najlepszym przybliżeniem numeru linii i kolumny) i obsługuje wszystkie typy danych JSON: ciągi znaków, liczby, wartości logiczne, null, tablice i obiekty.
Wynik YAML 1.2 przez eemeli/yaml Document API ze schematem YAML 1.1
YAML jest generowany przy użyciu biblioteki eemeli/yaml (v2.8+, bezpieczna pod kątem CVE) przez jej Document API z version: '1.1'. Ta kombinacja produkuje wynik zgodny z YAML 1.2, stosując jednocześnie reguły cytowania YAML 1.1 — co oznacza, że ciągi będące problemem Norway (yes/no/on/off/y/n) są automatycznie ujmowane w cudzysłowy w wynikowym pliku, co czyni go bezpiecznym zarówno dla parserów YAML 1.1, jak i 1.2. Zawijanie linii jest wyłączone (lineWidth: 0), aby zachować długie ciągi w całości.
100% w przeglądarce — bez przesyłania, bez serwera
Całe przetwarzanie odbywa się wyłącznie w silniku JavaScript przeglądarki. Żadne dane nie są przesyłane przez sieć w żadnym momencie. Dane wejściowe większe niż 200 KB automatycznie przełączają się z trybu na żywo na tryb ręczny (wymagający jawnego kliknięcia przycisku Konwertuj), aby utrzymać responsywność przeglądarki i zapobiec blokowaniu głównego wątku podczas intensywnej serializacji.

Dobre praktyki

Zawsze używaj trybu Auto do konfiguracji DevOps
Przy konwersji JSON do użytku w Kubernetes, Helm, Ansible, Docker Compose lub GitHub Actions zawsze używaj domyślnego trybu Auto (bezpiecznego dla Norway). Parsery YAML 1.1 w tych narzędziach cicho błędnie interpretują ciągi yes, no, on, off, y i n jako wartości logiczne — tryb Auto zapobiega temu w sposób przejrzysty.
Używaj wcięcia 2-spacjowego dla narzędzi cloud-native
Kubernetes, Docker Compose, GitHub Actions i Helm wszystkie używają wcięcia 2-spacjowego zgodnie z konwencją. Używanie wcięcia 4-spacjowego w tych plikach jest prawidłowym YAML, ale stworzy niespójność z przykładami społeczności, automatycznie generowanymi konfiguracjami i istniejącymi manifestami zespołu.
Przechowuj duże liczby całkowite jako ciągi znaków przed konwersją
Pola Kubernetes resourceVersion, uid i inne pola int64 z serwera API mogą przekraczać bezpieczny zakres liczb całkowitych JavaScript (2^53 - 1). Jeśli potrzebna jest dokładna precyzja numeryczna, przechowuj te wartości jako ciągi znaków JSON przed konwersją. Jest to szczególnie ważne dla wynikowego JSON kubectl get -o json zawierającego pola generowane po stronie serwera.
Waliduj JSON przed konwersją
Jeśli źródłem JSON jest ręcznie pisany tekst lub system, który czasem produkuje nieprawidłowe dane wyjściowe (przecinki kończące, klucze bez cudzysłowów, komentarze), sprawdź go narzędziem do formatowania JSON przed konwersją. Użyj naszego formatowania JSON, aby najpierw wykryć i naprawić błędy składni, a następnie przekonwertuj czysty JSON do YAML.
Preferuj styl blokowy dla plików trafiających do systemu kontroli wersji
Styl blokowy YAML tworzy przejrzyste, czytelne dla człowieka diffy w Git, bo każde pole pojawia się w osobnej linii. Styl przepływowy (zwarte, wbudowane) utrudnia czytanie i przeglądanie diffów. Zachowaj styl przepływowy do osadzania krótkich fragmentów YAML w dokumentacji lub dla narzędzi wymagających zwartego wyjścia.

Najczęściej zadawane pytania

Jak przekonwertować JSON na YAML online?
Wklej JSON do pola wejściowego powyżej. Narzędzie konwertuje go do YAML natychmiast w przeglądarce — bez klikania przycisku. W panelu Opcje można dostosować wcięcia (2 lub 4 spacje), styl cudzysłowów (Auto, Podwójne lub Pojedyncze) oraz styl wyjścia (Blokowy lub Przepływowy). Po pojawieniu się YAML w obszarze wyjściowym kliknij Kopiuj, aby przenieść go do schowka, lub Pobierz, aby zapisać jako plik .yaml. Wszystko działa lokalnie — dane nigdy nie opuszczają urządzenia.
Czym jest problem Norway w YAML i jak narzędzie go obsługuje?
Problem Norway w YAML odnosi się do specyfiki specyfikacji YAML 1.1, gdzie ciągi znaków takie jak "no", "yes", "on", "off", "y" i "n" są parsowane jako wartości logiczne (false/true) zamiast ciągów znaków. Spowodowało to znany przypadek z życia wzięty, gdy kod kraju ISO dla Norwegii ("NO") był błędnie odczytywany jako logiczne false w plikach Ansible playbook i konfiguracjach Kubernetes. W YAML 1.2 problem ten został naprawiony. Jednak miliony produkcyjnych parserów (starsze wersje Kubernetes, PyYAML, Ansible, Ruby Psych) nadal używają YAML 1.1. Domyślny tryb Auto tego narzędzia automatycznie ujmuje w cudzysłowy wszystkie ciągi będące problemem Norway, gwarantując bezpieczną konwersję w obie strony przez parsery zarówno YAML 1.1, jak i 1.2. Gdy w danych wejściowych wykryto takie ciągi, baner z ostrzeżeniem wymienia dokładnie, które wartości zostały automatycznie ujęte w cudzysłowy.
Dlaczego problem Norway ma znaczenie dla Kubernetes i DevOps?
Manifesty YAML Kubernetes, pliki Helm chart values, Ansible playbook i przepływy pracy GitHub Actions są parsowane przez narzędzia historycznie używające YAML 1.1. Jeśli klucz konfiguracji ma wartość "no" (np. kod kraju, flaga enabled w formie ciągu znaków lub niestandardowe pole boolowskie), parser YAML 1.1 cicho przekonwertuje ją na logiczne false. Może to powodować błędy konfiguracji usług niezwykle trudne do debugowania, bo YAML wygląda poprawnie jako tekst, ale zachowuje się inaczej po sparsowaniu. Przy konwersji JSON do użytku w Kubernetes lub innych narzędziach DevOps zawsze używaj trybu Auto, aby zapewnić bezpieczną konwersję w obie strony.
Czy stosować wcięcie 2 czy 4 spacje w YAML?
Stosuj wcięcie 2-spacjowe dla manifestów Kubernetes, Helm values, plików Docker Compose i przepływów pracy GitHub Actions — te narzędzia są projektowane wokół YAML z 2 spacjami i jest to konwencja społeczności. Stosuj wcięcie 4-spacjowe dla Ansible playbook (które używają konwencji 4-spacjowej) oraz gdy zespół lub organizacja ma przewodnik stylu to nakazujący. YAML całkowicie zabrania znaków tabulacji — wszystkie wcięcia muszą być spacjami. Narzędzie domyślnie używa 2 spacji, co jest właściwym wyborem dla zdecydowanej większości zastosowań cloud-native.
Jak użyć narzędzia do tworzenia manifestu Kubernetes?
Jeśli masz definicję zasobu Kubernetes w JSON (z kubectl get deployment my-app -o json, odpowiedzi API lub bloku zasobu Terraform), wklej ją do pola wejściowego. Wybierz wcięcie 2 spacje (domyślne) i cytowanie Auto (domyślne, które obsługuje problem Norway). Wynik YAML jest od razu gotowy do kubectl apply -f. Możesz też kliknąć Pobierz, aby zapisać plik z rozszerzeniem .yaml i przekazać go bezpośrednio przez kubectl apply -f -. Przykład K8s Deployment powyżej pokazuje kompletny manifest, który możesz załadować i zmodyfikować.
Jak przekonwertować JSON Docker Compose do YAML?
Wklej JSON Docker Compose do pola wejściowego. Użyj wcięcia 2-spacjowego (konwencja Docker Compose) i stylu blokowego. Wynikowy YAML jest zgodny z docker compose up, docker compose config i Docker Stack. Typowym scenariuszem jest eksport konfiguracji działającego stosu przez docker inspect, a następnie konwersja go z powrotem do pliku compose.yaml. Przykład Docker Compose powyżej zawiera definicje usług z portami, zmiennymi środowiskowymi, wolumenami i depends_on.
Czy liczby JSON większe niż 2^53 mogą tracić precyzję przy konwersji do YAML?
Tak. Jest to podstawowe ograniczenie JavaScript: typ Number w JavaScript używa 64-bitowej liczby zmiennoprzecinkowej IEEE 754, która może precyzyjnie reprezentować liczby całkowite tylko do 2^53 - 1 (9007199254740991). Każda liczba całkowita poza tym zakresem — np. pola resourceVersion Kubernetes (które są int64 po stronie serwera) — zostanie cicho zaokrąglona podczas parsowania przez JSON.parse(). Dotyczy to wszystkich narzędzi JSON opartych na przeglądarce, nie tylko tego. Bezpiecznym obejściem jest przechowywanie dużych liczb całkowitych jako ciągów znaków w JSON ("resourceVersion": "9007199254740993") — pojawią się one w YAML jako ciągi znaków bez utraty precyzji.
Czy konwerter zachowuje oryginalną kolejność kluczy z JSON?
Tak. Biblioteka eemeli/yaml używana przez to narzędzie zachowuje kolejność wstawiania, co odpowiada zachowaniu JSON.parse() we wszystkich nowoczesnych silnikach JavaScript (V8, SpiderMonkey, JavaScriptCore). Klucze pojawiają się w wynikowym YAML w tej samej kolejności, w jakiej występowały w wejściowym JSON. Jest to ważne dla manifestów Kubernetes i specyfikacji OpenAPI, gdzie kolejność pól często ma znaczenie dla czytelności i diffów.
Kiedy używać JSON, a kiedy YAML?
Używaj JSON gdy: tworzysz API i usługi webowe (JSON jest uniwersalnym formatem wymiany danych), gdy szybkość parsowania maszynowego ma znaczenie, gdy potrzebna jest ścisła kontrola typów lub gdy odbiorcą jest aplikacja JavaScript/TypeScript. Używaj YAML gdy: piszesz pliki konfiguracyjne przeznaczone do edycji przez człowieka (manifesty Kubernetes, potoki CI/CD, Ansible playbook, Helm values), gdy chcesz komentarzy w konfiguracji lub gdy czytelność jest ważniejsza niż ścisłość. Pomocna zasada: jeśli maszyna to pisze lub czyta jako pierwsza, użyj JSON; jeśli człowiek to pisze, a maszyna czyta, użyj YAML.
Jak przekonwertować JSON na YAML w wierszu poleceń?
Najpopularniejszym podejściem jest połączenie yq i jq. Zainstaluj yq (wersja Mike'a Faraha, nie pythonowa): brew install yq na macOS lub wget https://github.com/mikefarah/yq/releases/latest/download/yq_linux_amd64 -O /usr/local/bin/yq dla Linux. Następnie uruchom: cat input.json | yq -P dla pretty-print jako YAML. Alternatywnie: yq -o yaml input.json lub cat input.json | python3 -c "import sys, json, yaml; yaml.dump(json.load(sys.stdin), sys.stdout, default_flow_style=False)". Dla Kubernetes: kubectl get deployment my-app -o yaml konwertuje bezpośrednio z API klastra.
Jak przekonwertować JSON na YAML w Pythonie, Node.js lub Go?
W Pythonie: import json, yaml; yaml.dump(json.load(open('input.json')), open('output.yaml', 'w'), default_flow_style=False) używając PyYAML, lub ruamel.yaml dla pełnej wierności konwersji w obie strony. W Node.js: import { Document } from 'yaml'; const doc = new Document(JSON.parse(input), { version: '1.1' }); const result = doc.toString({ indent: 2, lineWidth: 0 }) — to ta sama biblioteka i podejście co w tym narzędziu. W Go: import gopkg.in/yaml.v3; json.Unmarshal(jsonBytes, &data); yaml.Marshal(data) — uwaga: Go YAML v3 używa domyślnie YAML 1.1, więc ciągi będące problemem Norway zostaną automatycznie ujęte w cudzysłowy.
Czy dane JSON są wysyłane na serwer podczas korzystania z narzędzia?
Nie. Cała konwersja odbywa się wyłącznie w przeglądarce przy użyciu JavaScript. Dane JSON nigdy nie są przesyłane przez sieć, nie są przechowywane na żadnym serwerze ani rejestrowane czy analizowane. Narzędzie jest bezpieczne do użytku z kluczami API, danymi uwierzytelniającymi baz danych, wewnętrznymi plikami konfiguracyjnymi, produkcyjnymi manifestami Kubernetes i innymi wrażliwymi danymi. Można to zweryfikować, otwierając zakładkę Sieć w przeglądarce — wklejenie JSON nie wyzwoli żadnych żądań sieciowych.
Czy jest limit rozmiaru dla danych wejściowych JSON?
Nie ma twardego limitu rozmiaru, ale duże dane wejściowe (powyżej 200 KB) automatycznie przełączają się z trybu na żywo na tryb ręczny. W trybie ręcznym pojawia się przycisk Konwertuj i konwersja uruchamia się tylko po jego kliknięciu — zapobiega to blokowaniu głównego wątku przeglądarki przez 200-500 ms przy każdym naciśnięciu klawisza. W przypadku bardzo dużych plików JSON (wielomegabajtowych) warto rozważyć narzędzia wiersza poleceń, takie jak yq lub jq, dla lepszej wydajności. Narzędzie sprawnie obsługuje typowe rzeczywiste ładunki, takie jak pełne eksporty przestrzeni nazw Kubernetes, duże specyfikacje OpenAPI i wielousługowe pliki Docker Compose.

Powiązane narzędzia

Zobacz wszystkie narzędzia →