글 정정 · 2026년 10월 10일: 큰 숫자 설명의 제목이 앞 문장에 붙어 보이던 문제를 고쳤습니다. “정렬 후 자릿수 손실” 구버전 그림도 글에서 빼고, 직접 실행할 수 있는 입력과 예상 결과로 바꿨습니다. 표지의 책은 AI 편집 이미지이지 도구 화면이 아닙니다.
도구 수정 · 2026년 10월 9일: 이전 도구는 큰 정수·소수의 자릿수를 바꾸고, 1e999를 null로 바꾸며 중복 키를 버렸습니다. 현재 정렬·압축·키 정렬·트리와 복사 결과는 원문 숫자 표기·문자열 이스케이프·모든 항목을 보존합니다. 아래 손실 설명은 구 JSON.parse/JSON.stringify 방식의 예시이며 현재 도구 결과가 아닙니다. 새 버전도 실제 비밀정보를 입력해도 안전하다는 보장은 아닙니다.
테스트용 API 응답을 붙여넣었더니 빨간 줄 하나에 Unexpected token. 어디가 문제인지 눈으로 훑다가 결국 괄호를 하나씩 세고 있습니다. JSON은 규칙이 단순한데, 그 단순함 때문에 작은 실수 하나가 전체 파싱을 막습니다. 어디가 깨졌는지부터 찾는 법을 정리합니다.
깨진 JSON, 어디가 문제인지부터
JSON 파서는 첫 번째 문법 오류에서 멈춥니다. 브라우저가 위치 정보를 제공하면 PiPi JSON 포맷터도 해당 줄·열을 보여줍니다. 이전 글은 한 줄짜리 코드를 보여주면서 “4행 1열”이라고 적었습니다. 그 불일치를 2026년 9월 28일 정정했습니다. 그림은 AI로 만든 편집용 이미지이며 실제 도구 화면이 아닙니다.
아래는 실제로 네 줄인 테스트 입력입니다.
{
"name": "PiPi",
"role": "editor",
}
현재 Chromium/V8에서 이 입력을 파싱하면 Expected double-quoted property name in JSON at position 40 (line 4 column 1)가 나옵니다. 3행 끝의 쉼표가 불필요하고, 4행의 }에서 다음 속성 이름을 기대하다 멈춘 것입니다. 3행 끝 쉼표를 지우면 유효해집니다. 같은 JSON을 { "name": "PiPi", "role": "editor", }처럼 한 줄로 입력하면 4행 오류가 아니라 1행 오류입니다. 오류 문구와 위치 정보의 제공 여부는 브라우저 엔진에 따라 다를 수 있습니다.
가장 자주 나오는 오류는 정해져 있습니다.
| 오류 | 증상 |
|---|---|
| trailing comma | 마지막 요소 뒤 불필요한 쉼표 |
| 따옴표 누락 | 키나 문자열을 큰따옴표로 안 감쌈 |
| 괄호 짝 안 맞음 | {·[ 를 닫지 않음 |
| 콜론 누락 | 키와 값 사이 : 빠짐 |
JSON은 작은따옴표, 주석, trailing comma를 허용하지 않습니다(RFC 8259). 자바스크립트 객체 리터럴과 헷갈려서 나는 실수가 많습니다.
보기 좋게 정렬하거나, 한 줄로 압축하거나
유효한 JSON이라면 들여쓰기를 입혀 구조를 한눈에 볼 수 있습니다. 2칸·4칸·탭 중 팀 컨벤션에 맞는 들여쓰기를 고르면 됩니다.
반대로 전송 크기를 줄여야 할 땐 압축으로 문자열 값 바깥의 불필요한 공백을 제거합니다. { "a": 1, "b": [1, 2, 3] } 는 {"a":1,"b":[1,2,3]} 한 줄이 됩니다. 같은 데이터를 보기용과 전송용으로 오가는 작업이라 자주 쓰게 됩니다.
샘플 1 · 정렬과 키 정렬은 다릅니다
API 응답의 키 순서만 달라 diff가 길어졌다면 키 정렬을 써 볼 수 있습니다. 그냥 정렬은 들여쓰기를 바꿀 뿐 키를 재배열하지 않습니다. 다음 입력을 붙여 넣고 네 모드를 차례로 눌러 보세요.
{"10":"ten","2":"two","01":"zero-one","z":[3,1,2],"a":"first"}
| 모드 | 객체 키의 출력 순서 | 배열 z |
|---|---|---|
| 정렬 | 10 → 2 → 01 → z → a | [3,1,2] |
| 압축 | 10 → 2 → 01 → z → a | [3,1,2] |
| 트리 | 10 → 2 → 01 → z → a | [3,1,2] |
| 키 정렬 | 2 → 10 → 01 → a → z | [3,1,2] |
키 정렬 모드만 정수 인덱스 키를 숫자 순으로 먼저 놓고, 나머지는 해석된 키의 자바스크립트 문자열 비교 순서로 정렬합니다. "01"은 이 도구에서 정수 인덱스가 아닌 문자열 키입니다. 이는 PiPi의 표시 규칙이지 모든 JSON 출력기의 공통 규칙이 아닙니다. RFC 8259 §4·§5에서 객체의 순서와 배열의 순서는 서로 구분됩니다. 이 도구는 어느 모드에서도 배열을 값순으로 정렬하지 않습니다.
키 정렬 결과의 들여쓰기 공백만 생략하면 다음과 같습니다.
{"2":"two","10":"ten","01":"zero-one","a":"first","z":[3,1,2]}
두 결과를 나란히 비교할 때에는 키 순서뿐 아니라 값과 중복 키 경고도 확인하세요. 표시가 같아 보인다는 이유만으로 데이터 계약이나 값의 동등성이 검증되지는 않습니다.
샘플 2 · 큰 숫자는 보존되지만 계산 검증은 아닙니다
아래는 10월 9일 수정 이전의 JSON.parse/JSON.stringify 방식에서 발생하던 손실입니다. 현재 도구 결과가 아니며 다른 자바스크립트 소비자의 정밀도 위험을 이해하기 위한 예시입니다. JSON 숫자는 자바스크립트에서 IEEE-754 배정밀도로 파싱됩니다.
문제는 안전 정수 범위를 넘어설 때입니다. {"id": 12345678901234567890} 을 구 방식으로 변환하면 {"id":12345678901234567000} 이 나옵니다. 뒷자리가 조용히 바뀐 겁니다. 자바스크립트의 안전한 정수 최대값은 2^53−1, 즉 9007199254740991입니다(MDN). 정확한 ID를 주고받아야 한다면 생산자·소비자 양쪽의 계약을 확인하고 문자열("12345678901234567890") 사용을 합의하세요. 이미 손실된 응답을 뒤늦게 문자열로 바꿔도 원래 자릿수는 돌아오지 않습니다.
다음 비민감 테스트 입력을 도구에 넣고 네 모드를 각각 확인하세요. 복사 결과에도 정확한 자릿수·1e999·-0·두 same 항목이 남아야 합니다. 중복 키 경고는 문법 오류가 아니라 상호운용성 경고입니다.
{"id":12345678901234567890,"decimal":0.123456789012345678901,"overflow":1e999,"zero":-0,"same":1,"same":2}
| 확인 대상 | 현재 도구 출력에서 보존되는 내용 |
|---|---|
| 큰 정수 | 12345678901234567890의 전체 자릿수 |
| 소수 | 0.123456789012345678901의 전체 표기 |
| 지수·음수 0 | 1e999, -0 그대로 — 계산·범위 검증 결과는 아님 |
| 중복 키 | same 두 항목과 경고 — 다른 파서는 하나를 선택할 수 있음 |
1e999는 JSON 숫자 문법에 맞지만 JavaScript의 유한한 숫자 범위를 넘습니다. 원문에 그대로 남아 있다는 사실은 계산 가능성·업무상 허용 범위를 보증하지 않습니다(RFC 8259 §6). 이미 다른 프로그램에서 반올림된 숫자는 이 도구가 복구할 수 없습니다. 원본 응답이나 계약된 문자열 ID와 대조하세요.
샘플 3 · 다르게 쓴 키도 중복일 수 있습니다
아래에서 "\u0061"과 "a"는 글자 표기가 다르지만 해석하면 같은 키 a입니다. RFC 8259 §8.3은 이스케이프를 해석한 문자열 비교를 설명합니다.
{"b":[3,2,1],"\u0061":1,"a":2,"2":9,"10":8,"01":7}
이 도구는 중복 키 경고를 표시하면서 두 항목과 원문 이스케이프를 모두 남깁니다. 정렬·압축·트리는 입력 순서를 유지하고 키 정렬은 아래 순서가 됩니다. 공백만 생략한 결과이며, 같은 키인 두 항목의 상대 순서와 배열 순서는 바뀌지 않습니다.
{"2":9,"10":8,"01":7,"\u0061":1,"a":2,"b":[3,2,1]}
반면 JavaScript JSON.parse로 이 입력을 읽은 소비자는 a의 마지막 값인 2를 남깁니다(ECMAScript JSON.parse). 모든 파서가 같다는 뜻은 아닙니다. 다른 구현은 오류를 내거나 모든 항목을 드러낼 수 있습니다(RFC 8259 §4). 중복 경고가 나오면 어느 항목이 의도된 값인지 생산자에게 확인하고, 합의 없이 한 항목을 삭제하지 마세요.
실제 응답을 확인하기 전, 30초 점검
- 운영 토큰·개인정보를 빼고 위 테스트 입력부터 넣습니다.
- 필요한 모드를 고릅니다. 키 비교는 키 정렬, 공백 제거는 압축입니다.
- 큰 숫자와 중복 키가 원문대로 남는지 결과를 봅니다. 트리에서도 두
a항목을 구분합니다. - 복사한 결과를 받을 프로그램의 숫자·중복 키 규칙을 별도로 확인합니다. 포맷터의 문법 통과 표시로 이 단계를 대신하지 않습니다.
그 API 응답, 어디에 붙여넣고 있나
마지막으로 짚을 점입니다. 디버깅용 JSON에는 액세스 토큰, 내부 ID, 개인정보가 섞여 있는 경우가 많습니다. 이런 값을 온라인 포맷터에 붙여 넣으면 노출 위험이 있습니다. 먼저 샘플이나 비민감 테스트 값으로 바꾸세요.
PiPi Worlds JSON 포맷터의 파싱 자체는 브라우저에서 실행됩니다. 그러나 이 사실만으로 운영 비밀의 안전을 보장할 수는 없습니다. 샘플 JSON 안의 base64 값은 Base64 도구로, 테스트용 JWT는 JWT 디코더로 구조를 살펴볼 수 있습니다. 운영 비밀은 승인된 로컬 작업 절차를 따르세요.