붙여넣은 데이터가 서버로 전송되나요?

전송되지 않습니다. 파싱과 직렬화 모두 브라우저의 JSON.parse와 JSON.stringify로 처리되며, 입력값을 외부로 보내는 네트워크 요청은 없습니다. 다만 회사 정책상 사내 데이터를 외부 웹사이트에 붙여넣는 것 자체가 금지된 경우가 있으니, 민감한 프로덕션 데이터라면 사내 규정을 먼저 확인하세요.

주석이 들어 있는 JSON은 왜 오류가 나나요?

표준 JSON에는 주석 문법이 없습니다. VS Code 설정 파일(settings.json)이나 tsconfig.json은 사실 JSONC라는 확장 형식이고, 이 편집기들이 주석을 허용해 주는 것입니다. 주석이 포함된 파일을 검증하려면 주석 줄을 먼저 지우고 넣으세요.

큰 파일도 처리할 수 있나요?

브라우저 메모리 안에서 처리하므로 수 MB 정도는 대개 문제가 없지만, 수십 MB를 넘어가면 탭이 멈출 수 있습니다. 큰 파일은 jq 같은 명령줄 도구(예: jq . data.json)를 쓰는 편이 안전합니다.

키 순서가 바뀌지 않나요?

바뀌지 않습니다. JSON.parse는 객체 키의 삽입 순서를 유지하고 JSON.stringify가 그 순서대로 다시 씁니다. 단, 키가 정수처럼 생긴 문자열("1", "2")이면 JavaScript 객체의 속성 순서 규칙에 따라 숫자 순으로 앞에 몰릴 수 있습니다.

숫자 정밀도가 손실될 수 있나요?

그럴 수 있습니다. JavaScript의 수는 배정밀도 부동소수점이라 안전한 정수 범위가 ±2^53-1입니다. 그보다 큰 ID(예: 트위터 스노플레이크 ID, 일부 DB의 bigint)는 파싱 후 값이 미세하게 달라질 수 있습니다. 이런 값은 API 설계 단계에서 문자열로 내려받는 것이 정석입니다.

유효성 검증과 스키마 검증은 다른 건가요?

다릅니다. 이 도구가 하는 것은 문법 검증, 즉 '파싱 가능한 JSON인가'입니다. 필수 필드가 있는지, 타입이 맞는지 같은 구조 검증은 JSON Schema의 영역이고, 그건 JSON Schema Generator 도구로 초안을 만들 수 있습니다.

JSON Formatter - JSON 포맷터

JSON 포맷터 사용 가이드와 파싱 오류 해결법

JSON은 규칙이 매우 적은 데이터 형식입니다. 그래서 배우기 쉽지만, 규칙이 적은 만큼 어긋났을 때 파서가 알려주는 정보도 빈약합니다. 이 도구는 붙여넣은 JSON을 들여쓰기해서 구조를 눈으로 확인하게 해주고, 문법이 깨진 경우 브라우저 파서가 내놓은 오류 메시지를 그대로 보여줍니다. 아래 내용은 그 오류 메시지를 해석하는 방법과, 포맷과 압축을 각각 어디에 써야 하는지에 대한 설명입니다.

표준 JSON이 허용하는 것과 허용하지 않는 것

많은 파싱 오류는 JavaScript 객체 리터럴과 JSON을 같은 것으로 착각해서 생깁니다. JSON은 JavaScript에서 파생됐지만 훨씬 좁은 규격(RFC 8259)이고, JavaScript에서 문제없이 쓰던 표기 상당수가 JSON에서는 오류입니다.

표기	표준 JSON	설명
{"a": 1}	허용	키는 반드시 큰따옴표로 감싼 문자열
{a: 1}	불가	따옴표 없는 키는 JavaScript 문법이지 JSON이 아님
{'a': 1}	불가	작은따옴표는 JSON에서 문자열 표시로 쓸 수 없음
{"a": 1,}	불가	마지막 요소 뒤 쉼표(trailing comma) 금지
// 주석	불가	JSON에는 주석 문법이 아예 없음
NaN, Infinity	불가	JSON의 수는 유한한 십진수만 가능 (null로 대체)
{"a": undefined}	불가	undefined는 JSON 값이 아님 (null 사용)
1e-7, -0.5	허용	지수 표기와 음수는 정상 JSON 수

사용 방법

왼쪽 입력창에 JSON을 붙여넣습니다. 한 줄로 압축된 API 응답이어도 그대로 넣으면 됩니다.
들여쓰기 폭을 2 spaces, 4 spaces, 1 tab 중에서 고릅니다. 팀 컨벤션이 없다면 2 spaces가 무난합니다.
정리(Format)를 누르면 오른쪽에 들여쓰기된 결과가 나옵니다. 문법이 깨져 있으면 결과 대신 빨간 오류 메시지가 표시됩니다.
압축(Minify)은 반대로 모든 공백과 줄바꿈을 제거해 한 줄로 만듭니다.
결과 위쪽의 통계로 키 개수, 객체/배열 수, 최대 중첩 깊이, 바이트 크기를 확인합니다.
복사 버튼으로 클립보드에 담거나, 다운로드로 .json 파일로 저장합니다.

오류 메시지 해석하기

이 도구는 브라우저의 JSON.parse가 던진 메시지를 가공하지 않고 보여줍니다. 메시지에 포함된 위치 정보(position N 또는 line N column M)가 가장 중요한 단서입니다. 다만 파서는 '문제가 처음 확정된 지점'을 알려주기 때문에, 실제 원인은 그보다 앞에 있는 경우가 많습니다. 예를 들어 여는 중괄호를 닫지 않으면 오류는 문서 맨 끝에서 보고됩니다.

메시지	원인	해결
Unexpected token ' ...	작은따옴표로 감싼 문자열	큰따옴표(")로 교체
Unexpected token } / ]	닫는 괄호 직전의 trailing comma	마지막 쉼표 삭제
Unexpected end of JSON input	괄호나 따옴표가 닫히지 않음	여는/닫는 짝 개수 확인
Unexpected token N / I	NaN 또는 Infinity	null이나 문자열로 치환
Bad escaped character	\ 뒤에 허용되지 않는 문자	\" \\ \/ \b \f \n \r \t \uXXXX만 사용
Unexpected non-whitespace ...	값 하나 뒤에 또 다른 값	JSON 문서 하나에 최상위 값은 하나뿐
Unexpected token o in JSON	문자열 "[object Object]"를 파싱	객체를 문자열로 잘못 연결한 코드 확인

Format과 Minify, 어디에 쓰는가

Format은 사람이 읽기 위한 변환입니다. 중첩 구조를 파악하거나, 응답에 예상한 필드가 들어 있는지 확인하거나, 코드 리뷰에 붙여 넣을 때 씁니다. 들여쓰기는 데이터의 의미를 바꾸지 않으므로 언제든 되돌릴 수 있습니다.

Minify는 전송량을 줄이기 위한 변환입니다. 공백과 줄바꿈을 없애면 보통 원본의 10~30% 정도가 줄어들고, 중첩이 깊고 키가 짧은 데이터일수록 감소폭이 큽니다. 다만 요즘 HTTP 응답은 대개 gzip이나 brotli로 압축되어 전달되므로, 압축 계층이 이미 반복되는 공백을 잘 처리합니다. 실제 이득은 압축을 쓰지 않는 경로, 예컨대 localStorage 저장, URL 쿼리 파라미터 삽입, 문자 수 제한이 있는 필드에 넣을 때 큽니다.

설정 파일은 Minify하지 마세요. package.json이나 tsconfig.json을 한 줄로 만들면 Git diff가 파일 전체 변경으로 잡혀 리뷰가 불가능해집니다.

구조 통계를 읽는 법

최대 깊이는 실무에서 가장 유용한 숫자입니다. 깊이가 6~7을 넘어가면 클라이언트 코드에서 옵셔널 체이닝이 길게 이어지고, 스키마 변경에 취약해집니다. 응답 설계를 다시 볼 신호로 삼을 만합니다.

키 개수와 바이트 크기를 함께 보면 페이로드에 실제로 필요한 데이터가 얼마나 들어 있는지 감을 잡을 수 있습니다. 목록 API 응답이 수백 KB인데 화면에서 쓰는 필드가 몇 개뿐이라면, 필드 선택 파라미터를 도입할 여지가 있다는 뜻입니다.

이런 작업에 씁니다

REST API·GraphQL 응답을 붙여넣어 필드 이름과 중첩 구조를 확인
GitHub, Stripe, Slack 웹훅 페이로드를 사람이 읽을 수 있게 정리
package.json, tsconfig.json, composer.json 같은 설정 파일의 문법 검증
MongoDB·Firestore 문서를 콘솔에서 복사해 구조 확인
JSON Lines 로그에서 한 줄을 떼어내 펼쳐 보기
로컬스토리지나 쿠키에 저장된 상태 값을 디코딩해 검사

자주 묻는 질문

붙여넣은 데이터가 서버로 전송되나요?: 전송되지 않습니다. 파싱과 직렬화 모두 브라우저의 JSON.parse와 JSON.stringify로 처리되며, 입력값을 외부로 보내는 네트워크 요청은 없습니다. 다만 회사 정책상 사내 데이터를 외부 웹사이트에 붙여넣는 것 자체가 금지된 경우가 있으니, 민감한 프로덕션 데이터라면 사내 규정을 먼저 확인하세요.
주석이 들어 있는 JSON은 왜 오류가 나나요?: 표준 JSON에는 주석 문법이 없습니다. VS Code 설정 파일(settings.json)이나 tsconfig.json은 사실 JSONC라는 확장 형식이고, 이 편집기들이 주석을 허용해 주는 것입니다. 주석이 포함된 파일을 검증하려면 주석 줄을 먼저 지우고 넣으세요.
큰 파일도 처리할 수 있나요?: 브라우저 메모리 안에서 처리하므로 수 MB 정도는 대개 문제가 없지만, 수십 MB를 넘어가면 탭이 멈출 수 있습니다. 큰 파일은 jq 같은 명령줄 도구(예: jq . data.json)를 쓰는 편이 안전합니다.
키 순서가 바뀌지 않나요?: 바뀌지 않습니다. JSON.parse는 객체 키의 삽입 순서를 유지하고 JSON.stringify가 그 순서대로 다시 씁니다. 단, 키가 정수처럼 생긴 문자열("1", "2")이면 JavaScript 객체의 속성 순서 규칙에 따라 숫자 순으로 앞에 몰릴 수 있습니다.
숫자 정밀도가 손실될 수 있나요?: 그럴 수 있습니다. JavaScript의 수는 배정밀도 부동소수점이라 안전한 정수 범위가 ±2^53-1입니다. 그보다 큰 ID(예: 트위터 스노플레이크 ID, 일부 DB의 bigint)는 파싱 후 값이 미세하게 달라질 수 있습니다. 이런 값은 API 설계 단계에서 문자열로 내려받는 것이 정석입니다.
유효성 검증과 스키마 검증은 다른 건가요?: 다릅니다. 이 도구가 하는 것은 문법 검증, 즉 '파싱 가능한 JSON인가'입니다. 필수 필드가 있는지, 타입이 맞는지 같은 구조 검증은 JSON Schema의 영역이고, 그건 JSON Schema Generator 도구로 초안을 만들 수 있습니다.

💡 참고: 오류 위치가 문서 맨 끝으로 보고된다면 거의 항상 괄호나 따옴표를 닫지 않은 경우입니다. 이때는 입력을 절반으로 나눠 각각 넣어 보면 어느 쪽에 문제가 있는지 빠르게 좁힐 수 있습니다.

{ }JSON 포맷터