JSON은 사람이 읽으라고 만든 형식이지만, 정작 실무에서 마주치는 JSON은 한 줄로 압축된 수천 자짜리 응답인 경우가 대부분입니다. 이 도구는 그런 덩어리를 들여쓰기해 구조를 드러내고, 반대로 배포용으로 다시 압축합니다. 무엇보다 문법이 깨졌을 때 몇 행 몇 열에서 어긋났는지 정확히 짚어 줍니다.
오류 위치를 직접 계산한다는 점이 일반적인 포맷터와 다릅니다. 브라우저마다 JSON.parse가 내놓는 오류 메시지가 제각각이라 — 최신 크롬은 위치를 아예 빼고, 파이어폭스는 행·열을 주고, 사파리는 아무 정보도 주지 않습니다 — 이 도구는 RFC 8259 문법을 따라 입력을 직접 훑어 첫 번째로 깨지는 지점을 찾아냅니다. 그래서 어떤 브라우저에서 열어도 같은 위치를 알려 줍니다.
사용 방법
- JSON 붙여넣기 — 왼쪽 입력창에 JSON을 붙여넣습니다. 한 줄로 압축된 API 응답이든 여러 줄짜리 설정 파일이든 상관없습니다. 유효한 JSON이면 오른쪽에 정렬된 결과가 즉시 나타나고, 아래에 객체·배열·키 개수와 최대 중첩 깊이가 표시됩니다.
- 들여쓰기 정하기 — 2칸, 4칸, 탭 중에서 고르거나 압축을 눌러 공백을 모두 제거합니다. 압축했을 때는 원본 대비 몇 퍼센트가 줄었는지 배지로 보여 주므로, 응답 크기를 줄이는 작업의 효과를 바로 확인할 수 있습니다.
- 키 정렬로 두 응답 비교하기 — 키 알파벳순 정렬을 켜면 객체의 키 순서를 통일합니다. 같은 API의 응답 두 개를 비교할 때 키 순서만 달라서 diff가 지저분해지는 문제를 없애 줍니다. 배열은 순서 자체가 의미를 가지므로 건드리지 않습니다.
- 경로로 값 꺼내기 — 아래 경로로 값 찾기에
items[0].sku처럼 입력하면 해당 위치의 값만 뽑아 보여 줍니다. 경로가 중간에서 끊기면 어디까지 존재하는지 알려 주므로, 깊이 중첩된 응답에서 필드 이름을 잘못 짚었는지 빠르게 확인할 수 있습니다.
자주 묻는 질문
주석이 들어간 JSON(JSONC)도 처리되나요?
처리되지 않습니다. // 나 /* */ 주석, 후행 쉼표(trailing comma), 따옴표 없는 키는 모두 표준 JSON이 아니어서 오류로 표시됩니다.
tsconfig.json 이나 VS Code 설정처럼 주석을 허용하는 파일은 JSONC라는 별도 방언입니다. 이런 파일을 다룰 때는 주석을 지운 뒤 붙여넣으세요. 후행 쉼표는 오류 위치로 정확히 표시되므로 어디를 지워야 하는지 바로 보입니다.
숫자가 조금씩 바뀌어서 나옵니다.
JSON의 숫자는 자바스크립트에서 배정밀도 부동소수점(double)으로 읽힙니다. 그래서 2^53(약 9007조)을 넘는 정수는 정밀도가 손실됩니다. 예를 들어 트위터의 예전 트윗 ID 같은 64비트 정수는 마지막 몇 자리가 달라집니다.
이건 이 도구의 문제가 아니라 자바스크립트 JSON.parse의 근본적인 한계이며, 브라우저 콘솔에서 직접 파싱해도 같은 결과가 나옵니다. 큰 정수를 다루는 API는 대부분 이 문제를 알고 있어서 ID를 문자열로 내려 줍니다. 직접 API를 설계한다면 같은 방식을 권합니다.
'문자열로 이스케이프'는 언제 쓰나요?
JSON을 다른 코드 안에 문자열 리터럴로 박아 넣어야 할 때 씁니다. 테스트 픽스처, 셸 스크립트의 curl -d 인자, 또는 JSON 안에 JSON을 문자열로 담는 로그 포맷 같은 경우입니다.
반대로 이스케이프 해제는 로그에서 {\"user\":{\"id\":1}} 처럼 이스케이프된 채로 찍힌 값을 원래 JSON으로 되돌릴 때 씁니다. 되돌린 뒤 다시 정렬 모드로 바꾸면 구조를 볼 수 있습니다.
아주 큰 JSON도 다룰 수 있나요?
수 MB 정도까지는 무리 없이 동작합니다. 다만 모든 처리가 브라우저 메인 스레드에서 일어나므로 수십 MB짜리 파일을 넣으면 정렬하는 동안 화면이 잠시 멈출 수 있습니다.
로그 덤프처럼 큰 파일은 jq 같은 CLI 도구가 더 적합합니다. jq . input.json 으로 정렬하고 jq -c . 로 압축할 수 있습니다. 이 도구는 응답 하나를 빠르게 들여다보는 용도에 맞춰져 있습니다.
알아두면 좋은 개념
JSON이 허용하지 않는 것들
JSON은 의외로 엄격합니다. 키는 반드시 큰따옴표로 감싸야 하고, 작은따옴표는 허용되지 않으며, 마지막 요소 뒤의 쉼표도 오류입니다. NaN, Infinity, undefined 는 값으로 쓸 수 없고, 숫자는 01 처럼 앞에 0을 붙일 수 없습니다.
자바스크립트 객체 리터럴과 비슷해 보이지만 같지 않다는 점이 혼동의 원인입니다. 코드에서 그냥 쓰던 표기를 JSON 파일에 옮겨 적었다가 파싱이 실패하는 일이 흔합니다. 이 도구가 짚어 주는 오류 위치는 대부분 이 다섯 가지 중 하나입니다.
왜 오류 메시지에 위치가 없어졌나
예전 V8(크롬·Node)은 Unexpected token } in JSON at position 42 처럼 오프셋을 알려 줬습니다. 그런데 최근 버전은 Unexpected token '}', "{\"a\": }" is not valid JSON 형태로 바뀌면서 위치 정보를 빼고 입력 일부를 대신 보여 줍니다. 짧은 입력에는 친절하지만 긴 JSON에서는 오히려 찾기 어려워졌습니다.
그래서 위치를 알아야 하는 도구들은 엔진 메시지에 기대지 않고 직접 파싱합니다. 이 도구도 마찬가지로, 값·객체·배열·문자열·숫자를 순서대로 훑으며 문법이 처음 어긋나는 문자 오프셋을 찾아 행과 열로 환산합니다.
압축이 실제로 얼마나 도움이 되는가
들여쓰기를 제거하면 보통 원본의 15~30%가 줄어듭니다. 다만 실제 HTTP 응답은 대부분 gzip이나 brotli로 압축되어 전송되는데, 반복되는 공백은 압축 알고리즘이 아주 잘 처리하는 패턴이라 전송량 차이는 생각보다 작습니다.
압축이 확실히 의미 있는 곳은 따로 있습니다. localStorage처럼 용량 제한이 있는 저장소, 압축이 적용되지 않는 WebSocket 메시지, 그리고 문자 수로 과금하는 API 요청 본문입니다. 반대로 Git에 커밋하는 설정 파일은 정렬된 상태로 두는 편이 diff를 읽기 훨씬 쉽습니다.