모든 처리는 브라우저 내부에서 실행됩니다 — 파일·입력은 서버로 전송되지 않습니다.
변환 방향(JSON → YAML 또는 YAML → JSON)을 전환하고 왼쪽에 원본을 붙여 넣으면 오른쪽에 변환 결과가 표시됩니다. Swap 버튼은 현재 출력을 입력으로 되돌리고 방향을 뒤집어 줍니다. 설정의 왕복 확인이나 양방향 변환 결과 비교에 유용합니다. 파싱 에러는 줄·열 번호로 표시되어 구조 문제를 빠르게 찾을 수 있습니다.
포맷 취향이 다른 시스템 사이에서 설정을 옮길 때 사용하세요. 누군가 JSON으로 작성한 Kubernetes 매니페스트를 `kubectl`이 기대하는 YAML로 변환한다거나, API 출력에서 Helm `values.yaml`을 생성한다거나, Terraform JSON 변수 파일을 Kustomize 패치에 흘려 넣는 식입니다. 두 포맷은 데이터 모델이 같으므로(JSON은 YAML 1.2의 엄격한 부분 집합) 대부분의 설정에서 왕복으로 정보 손실이 없습니다. 처리는 `yaml` 라이브러리로 브라우저 안에서 끝납니다. 내부 호스트명이나 시크릿이 포함된 설정에도 안심하고 사용할 수 있습니다.
{"name":"sample","version":"1.0.0","ports":[80,443],"env":{"production":true,"region":"us-east-1"}}name: sample version: 1.0.0 ports: - 80 - 443 env: production: true region: us-east-1
가장 잦은 용도입니다. 기계가 생성한 JSON(API 응답·Terraform 플랜 출력 등)을 사람이 풀 리퀘스트에서 읽기 좋은 들여쓰기 YAML로 바꿉니다. 2 스페이스 들여쓰기는 Kubernetes·Helm·GitHub Actions 관례에 맞춰져 있습니다.
# Production config name: api version: 1.0.0 replicas: 3 # bumped 2024-Q2 features: - search # GA - billing # beta
{
"name": "api",
"version": "1.0.0",
"replicas": 3,
"features": [
"search",
"billing"
]
}JSON에는 주석 구문이 없으므로 `#` 줄과 인라인 주석은 모두 사라집니다. 앵커(`&base`)와 앨리어스(`*base`)도 대상 값으로 펼쳐집니다. 주석을 유지하려면 YAML을 원본으로 두고 소비 시점에만 JSON으로 다시 변환하는 식으로 운용하세요.
name: release released: 2024-05-27 expires: 2025-05-27T00:00:00Z
{
"name": "release",
"released": "2024-05-27",
"expires": "2025-05-27T00:00:00.000Z"
}YAML에는 날짜·타임스탬프 스칼라 타입이 있지만 JSON에는 없습니다. 변환기는 JSON 출력 시 `Date` 객체를 ISO 8601 문자열로 직렬화합니다. 결과를 다시 JSON → YAML 변환하면 `released` 필드는 날짜가 아닌 문자열로 돌아오므로 왕복에서 타입이 항상 보존되지는 않습니다.
JSON에서 시작하면 거의 무손실입니다. JSON은 YAML 1.2의 엄격한 부분 집합이므로 JSON → YAML → JSON은 모든 값을 보존합니다. 반대 방향에서는 YAML 고유 기능(주석, 앵커·앨리어스(인라인 전개), `!!set`·`!!binary` 같은 태그 타입, 날짜·무한대 같은 풍부한 스칼라 타입)이 사라집니다. 왕복 충실도가 중요하면 표현력이 더 높은 YAML을 원본으로 두고 필요할 때만 JSON을 생성하세요.
모두 펼쳐집니다. `*default` 같은 앨리어스는 대응하는 `&default` 앵커의 값으로 치환되므로 JSON 출력에는 앨리어스가 나타난 모든 위치에 같은 서브트리가 반복됩니다. 의미적으로는 옳지만 공유에 의한 중복 제거 의도는 사라집니다. JSON → YAML로 되돌리면 앵커 없는 완전 전개 YAML이 나옵니다. 긴 설정 파일이나 공유 블록을 많이 쓰는 k8s 매니페스트에서 앵커를 유지하고 싶다면 YAML에 머물러 YAML 네이티브 도구를 쓰세요.
지원하지 않습니다. 이 변환기는 단일 문서를 가정합니다. JSON에는 다중 최상위 문서라는 개념이 없으므로 5문서 YAML을 변환하려면 배열(`[{...}, {...}, ...]`)로 감싸야 하며, 이는 의미 있는 변경이므로 의식적으로 수행해야 합니다. 문서마다 개별 변환하거나, 배열로 묶고 싶다면 먼저 `^---$`로 YAML을 나눈 뒤 결과를 합치세요.
YAML에서 null은 3가지로 표현할 수 있습니다. 명시 `null`, 틸드 `~`, 값을 비우기(`key:` 뒤에 아무것도 없음)입니다. 이 라이브러리는 모호함을 피하기 위해 명시 `null`을 기본으로 합니다. 왕복이 안전하고, 읽는 사람도 "비워 두는 것을 잊은" 게 아니라 "null로 의도한" 것임을 알 수 있습니다. 베어 형식을 엄격히 요구하는 도구에 맞추려면 `sed 's/: null$/:/g'` 등으로 후처리하세요. 의미는 동일합니다.
베어로 두면 의미가 바뀌는 경우에 시리얼라이저가 따옴표를 붙입니다. `"yes"`는 YAML 1.1 파서가 불리언 true로 읽지 않도록 `'yes'`가 됩니다. `"123"`은 정수가 아니라 문자열로 유지하기 위해 `'123'`이 됩니다. `*`·`&`·`!`·`|`·`>`로 시작하는 문자열은 그 바이트가 YAML 의미를 갖기 때문에 따옴표가 필요합니다. 원칙은 일관됩니다. 베어 스칼라가 의도한 문자열과 다른 타입으로 파싱될 수 있는 경우 라이브러리가 따옴표를 붙입니다.
Validator는 검증 전용으로 YAML 구문을 점검하고 에러를 줄 번호와 함께 나열합니다. Converter는 입력을 파싱해 메모리 트리를 걸어 다른 포맷으로 재출력합니다. Converter도 묵시적으로 검증은 수행합니다(파싱 실패는 에러 표시) — 거기에 더해 포맷 변환까지 합니다. YAML 파일에 대해 가부만 알고 싶다면 Validator, 실제로 다른 포맷이 필요할 때는 Converter를 골라 쓰세요.
JSON과 YAML은 같은 논리 데이터 모델(스칼라·시퀀스·매핑)을 공유하므로 변환 작업의 대부분은 같은 트리를 둘러싼 구문을 갈아 끼우는 일입니다. JSON은 의도적으로 미니멀합니다. 큰따옴표 문자열, 주석 없음, 끝 콤마 없음, 프리미티브 4종(문자열·숫자·불리언·null)에 배열과 객체. YAML 1.2는 JSON을 유효한 부분 집합으로 명시하므로 JSON 문서는 변경 없이 YAML로 파싱됩니다. 그러나 화살표를 뒤집어도 항상 깔끔히 돌아오지는 않습니다. YAML은 주석, 중복 제거를 위한 앵커와 앨리어스, 다중 문서 스트림, 블록 스칼라(`|`는 줄바꿈 보존, `>`는 접음), 태그 타입(`!!set`·`!!binary`·`!!timestamp`)을 추가로 갖고, 이것들은 JSON에는 자리가 없습니다.
실용적 경계는 **기계가 소비하느냐, 사람이 편집하느냐**입니다. JSON은 와이어 포맷을 지배합니다. REST API 바디, NoSQL 도큐먼트 스토어, 브라우저 `localStorage`, 로그 전송 등입니다. 강성이 장점으로, 주석 행이 실수로 파서를 깨뜨릴 일도 없고 공백 모호함도 없습니다. YAML은 사람이 손으로 편집하는 설정을 지배합니다. Kubernetes 매니페스트, GitHub Actions 워크플로, Ansible 플레이북, Docker Compose, Helm 차트 등입니다. 유연성(주석·다중 줄 문자열·앵커)이 들여쓰기의 엄격함을 보상합니다. 흔한 패턴은 YAML로 작성하고 런타임에는 JSON을 넘기는 것이며, `helm template`이 바로 이것을 합니다.
인접한 3가지 포맷도 알아 둘 가치가 있습니다. **TOML**은 YAML과 마찬가지로 설정용이지만 더 엄격하고 모호함이 적은 구문을 갖습니다 — Rust의 `Cargo.toml`, Python의 `pyproject.toml`, Hugo 설정에서 흔합니다. **HCL**(HashiCorp Configuration Language)은 Terraform을 받치며 블록 지향 구문과 임베디드 식을 가집니다. **JSON5·JSONC**는 JSON에 주석과 끝 콤마를 덧붙여 JSON 패밀리를 벗어나지 않으면서 사람 편집의 여지를 만듭니다 — `tsconfig.json`과 VS Code의 `settings.json`이 후자입니다. 각자 가독성과 엄격함의 스펙트럼에서 서로 다른 점을 고른 것이며, YAML과 JSON은 각각의 끝에서 툴링이 가장 두꺼운 자리를 차지합니다.
YAML 구문을 검증하고 모든 에러를 줄/열 번호와 함께 표시합니다. k8s, GitHub Actions, CI 설정 검증에 적합합니다.
CSV와 JSON을 양방향으로 변환합니다. RFC 4180을 따르므로 따옴표나 줄바꿈이 들어간 필드도 처리하며, 구분자와 헤더 옵션도 조절할 수 있습니다.
JSON을 정렬하고 검증합니다. 들여쓰기 출력, 압축 출력, 명확한 에러 위치 표시를 지원합니다.
JSON 문서를 JSON Schema(기본 Draft 2020-12)로 검증합니다. 실패 경로와 사유를 표시하며, Ajv로 브라우저 안에서 완전히 처리합니다.