JSON 포매터 & 검증기
JSON 정렬 · 검증 · 압축을 브라우저에서 즉시 실행. API 응답 확인 및 설정 파일 정리에.
📖 자주 걸리는 지점
JSON 의 정형 · 검증 · 압축을 브라우저 안에서 합니다. 정형했을 뿐인 것처럼 보여도 실제로는 한 번 파싱해 다시 쓰고 있으므로 값이 바뀌는 경우가 있습니다 — JSON 의 파서는 숫자를 어떻게 표현할지, 중복된 키를 어떻게 할지를 사양이 완전히 정하고 있지 않으므로 그 부분은 구현에 맡겨져 있습니다. 정형 전과 정형 후에 의미가 바뀌지 않는다는 보장은 사실 없습니다.
| 사례 | 무슨 일이 일어나는가 | 어떻게 하면 되는가 |
|---|---|---|
| 큰 정수가 정형했을 뿐인데 바뀐다 | JavaScript 의 JSON.parse 는 모든 숫자를 배정밀도 부동소수점으로 읽어들입니다 — 따라서 2 의 53 제곱을 넘는 정수는 정확히 표현할 수 없고 가까운 값으로 반올림됩니다. 9007199254740993 을 정형하면 9007199254740992 가 되고 에러도 경고도 나오지 않습니다. 실무에서 위험한 것은 Twitter 나 Discord 같은 큰 ID, Snowflake ID, 데이터베이스의 BIGINT 기본 키로 정형해 다시 붙인 데이터가 원본과는 다른 레코드를 가리키게 됩니다. 정형했을 뿐이라고 여기는 사이에 값이 깨지므로 의심할 이유가 생기기 어려운 것이 최대의 문제입니다. |
큰 ID 는 문자열로 가지세요 — "id": "9007199254740993" 이라고 따옴표를 붙이면 파서는 숫자로 변환하지 않으므로 값은 유지됩니다. 실제로 Twitter 의 API 는 일찍부터 이 문제에 대응해 id_str 이라는 필드를 따로 반환하고 있었습니다 — 계산에 쓰지 않는 숫자는 문자열로 한다는 것은 이 분야에서는 확립된 설계 판단입니다. 기존 데이터를 다루는 경우에는 정형 대상에 큰 정수가 포함되어 있지 않은지를 먼저 확인하세요 — 판별은 간단해서 16 자리를 넘는 숫자가 있으면 의심하는 것뿐입니다(2 의 53 제곱은 9,007,199,254,740,992 로 16 자리). 그리고 정형 전후로 diff 를 뜨는 습관을 가지세요 — 의도하지 않은 값의 변화는 그것으로밖에 발견되지 않습니다. |
| 중복된 키가 조용히 하나로 줄어든다 | {"a":1,"a":2} 처럼 같은 키가 두 번 나타나는 JSON 은 사양상 동작이 미정의입니다 — RFC 8259 는 유일해야 한다고 말하고 있지만 중복했을 때 어떻게 할지는 정하고 있지 않습니다. 실제 구현은 거의 모두 뒤에 나타난 쪽으로 덮어쓰므로 정형하면 {"a":2} 가 되고 첫 번째 값은 흔적도 없이 사라집니다. 설정 파일에서 이것이 일어나면 심각해서 설정을 썼는데 듣지 않는다는 증상의 원인이 위쪽에 같은 키가 이미 쓰여 있었던 것이었다는 것은 흔한 이야기입니다. 정형은 그 증거까지 지워 버립니다. |
설정 파일의 JSON 에서는 중복 키를 검출할 수 있는 린터를 쓰세요 — jsonlint 나 에디터의 JSON 확장 상당수가 경고를 냅니다. 정형 도구는 중복을 해결해 버리므로 검출에는 쓸 수 없습니다 — 이 둘은 목적이 다르다고 이해해 두세요. 그리고 중복 키가 발견되었을 때는 어느 쪽이 옳은가가 아니라 왜 두 개 쓰였는가를 확인하세요 — 많은 경우 복사 붙여넣기로 설정을 추가했을 때 기존 기술을 알아채지 못했다는 경위가 있고 한쪽을 지우는 것만으로는 같은 일이 재발합니다. 설정이 길어져 왔다면 키를 알파벳순으로 늘어놓아 두면 중복이 눈으로 보이게 됩니다. |
| 주석이 있는 JSON 이 에러가 된다 | 표준 JSON 에 주석은 없습니다. 이는 간과가 아니라 사양을 만든 Douglas Crockford 가 의도적으로 뺀 것으로 — 주석이 파서에 대한 지시자로 쓰이기 시작해 호환성을 깨뜨리는 것을 피하기 위해서였습니다. 그런데 실무에서는 tsconfig.json · .vscode/settings.json · .eslintrc.json 처럼 주석을 허용하는 설정 파일이 널리 쓰이고 있습니다 — 이들은 JSONC(JSON with Comments)라는 다른 방언이며 표준 JSON 파서에 통과시키면 반드시 실패합니다. JSON 이라고 생각했던 것이 JSON 이 아니었다는 것이 이런 종류의 에러의 정체입니다. |
JSONC 를 다룬다면 전용 파서를 쓰세요 — Node 라면 jsonc-parser, VS Code 의 설정을 읽는 도구는 이것을 쓰고 있습니다. 주석을 포함하는 JSON 을 표준 JSON 으로 변환하고 싶다면 주석을 삭제하고 나서 통과시킵니다 — 다만 그 시점에 주석에 쓰여 있던 정보는 사라지므로 변환한 결과를 원래 파일에 되돌려 쓰지 마세요. 더 넓은 판단으로 — 설정 파일에 주석이 필요하다면 애초에 JSON 이 아니라 YAML 이나 TOML 을 고르는 편이 솔직합니다. 왜 이 값인지를 남길 수 없는 포맷은 설정 파일로서 중요한 성질을 하나 결여하고 있습니다 — 반년 뒤에 읽는 사람에게 그 한 줄의 주석이 설정 그 자체보다 가치를 갖는 일은 드물지 않습니다. |
정형은 차분을 읽을 수 있게 하기 위해 가장 잘 듣습니다. API 의 응답을 테스트의 고정 데이터로서 저장소에 둔다면 정형하고 나서 커밋하세요 — 압축된 한 줄의 JSON 은 한 글자 바뀐 것만으로 diff 가 전 행이 되어 리뷰가 불가능해집니다. 다만 키의 순서에는 주의가 필요합니다 — 정형 도구나 언어에 따라서는 키를 알파벳순으로 재배열하는 것이 있고 그 경우는 첫 커밋에서 전 행 차분이 됩니다. 정형할지뿐 아니라 키를 정렬할지까지 팀에서 정해 CI 로 기계적으로 적용하세요 — 사람마다 설정이 다르면 의미 없는 차분이 리뷰를 뒤덮습니다. 마지막으로 보안의 주의를 하나 — API 응답을 정형 도구에 붙이기 전에 Authorization 헤더나 토큰이 본문에 포함되어 있지 않은지를 확인하세요. 이 페이지는 브라우저 안에서 끝나지만 같은 조작을 다른 온라인 도구에서 하는 습관이 들면 언젠가 프로덕션의 토큰을 외부로 보내게 됩니다.
📖 사용법
-
1
JSON 붙여넣기API 응답이나 설정 파일에서 JSON을 복사하여 입력란에 붙여넣습니다.
-
2
포맷 또는 압축 선택들여쓰기 폭 선택 후 포맷 버튼을 누르면 읽기 쉽게 펼쳐집니다.
-
3
검증 및 수정구문 오류 시 줄 번호와 원인을 표시합니다.
❓ 자주 묻는 질문
주석 포함 JSON도 처리되나요?
입력 데이터가 서버로 전송되나요?
거대한 JSON도 처리되나요?
키를 알파벳순으로 정렬할 수 있나요?
🐛 이 도구에서 문제가 발생했나요?
무료 · 가입 불필요. 재현 절차만이라도 도움이 됩니다. 보고는 운영자에게 직접 전달되어 개선에 사용됩니다.
보고 감사합니다!
운영자에게 전달되었습니다. 개선에 사용됩니다.