JSON 포매터

JSON을 정렬·압축·검증합니다. 들여쓰기를 선택하여 읽기 쉽게 정렬하거나 한 줄로 압축할 수 있습니다. 구문 오류도 즉시 확인할 수 있습니다.

JSON 입력
정렬 결과 유효한 JSON 유효하지 않은 JSON
{{ result.lines }} 줄 / {{ result.bytes.toLocaleString() }} 바이트
{{ result.error }}

JSON 포맷터란

JSON 포맷터는 한 줄에 빽빽이 들어찬 읽기 어려운 JSON을 들여쓰기가 있는 모습으로 다시 다듬거나, 거꾸로 공백을 걷어내어 한 줄로 압축하는 도구입니다. 입력을 해석하는 김에 구문이 올바른지도 판정하므로, API 응답이나 설정 파일을 붙여 넣기만 하면 정형·압축·검증의 세 가지를 한꺼번에 하실 수 있습니다. 들여쓰기는 공백 2칸·공백 4칸·탭 가운데 고르실 수 있습니다.

판정에는 브라우저 자신의 JSON 파서를 쓰므로, ‘이 도구에서는 통과하는데 실행 환경에서는 넘어진다’는 어긋남이 생기지 않습니다. 처리는 모두 쓰시는 기기 안에서 끝나며, 붙여 넣으신 JSON이 서버로 전송되는 일은 없습니다. 인증 토큰이나 개인정보가 담긴 API 응답이라도 내용을 밖으로 내보내지 않고 정형하실 수 있습니다.

JSON 포맷터 사용 방법

  1. JSON을 붙여 넣습니다 왼쪽 입력란에 JSON을 붙여 넣습니다. 손에 시험할 데이터가 없으시면 ‘샘플’ 버튼으로 예를 불러오실 수 있습니다.
  2. 들여쓰기의 너비를 고릅니다 공백 2칸·공백 4칸·탭 가운데 고릅니다. 프로젝트의 정형 규칙에 맞추어 두시면 그대로 붙여 되돌리실 수 있습니다.
  3. 유효·무효의 표시를 살핍니다 입력과 동시에 ‘유효한 JSON’·‘무효한 JSON’ 배지가 바뀝니다. 무효한 경우에는 파서가 돌려준 오류 메시지가 그대로 표시되므로, 몇 번째 줄의 어느 글자에서 막혔는지 좇으실 수 있습니다.
  4. 정형본인지 압축본인지 골라 복사합니다 ‘정형된 것 복사’는 들여쓰기가 있는 결과를, ‘압축된 것 복사’는 공백을 걷어낸 한 줄의 결과를 클립보드에 담습니다.
  5. 줄 수와 바이트 수를 확인합니다 줄 수는 정형 후의 결과를, 바이트 수는 압축 후의 결과를 UTF-8로 센 값입니다. 전송량을 어림하실 때는 뒤엣것을 보아 주세요.

더 잘 활용하기 위한 팁

  • JSON의 키는 반드시 큰따옴표로 감싸야 합니다. 작은따옴표는 유효하지 않습니다.
  • 후행 쉼표({"a":1,})는 JSON 사양상 유효하지 않습니다.
  • 숫자는 e 표기법도 유효합니다. 단, NaN·Infinity는 유효하지 않습니다.
  • 문자열 내의 큰따옴표는 \"로 이스케이프해야 합니다. 줄 바꿈은 \n, 탭은 \t입니다.
  • 압축은 파일 크기 절감에 유효합니다. API 전송에는 압축 버전, 설정 파일에는 정렬 버전이 적합합니다.

JSON 포맷터의 활용 상황

API 응답의 내용을 읽기

한 줄로 돌아온 응답을 정형하시면, 중첩의 깊이나 배열의 요소 수를 눈으로 좇으실 수 있게 됩니다. 개발 중의 동작 확인이나 버그 조사에서 가장 잦은 쓰임입니다.

설정 파일의 구문 오류를 짚어내기

앱이 설정 파일을 읽어 들이지 못할 때, 붙여 넣어 검증하시면 끝의 쉼표나 따옴표를 닫지 않은 곳 같은 원인을 그 자리에서 특정하실 수 있습니다.

전송량을 줄이기 위해 압축하기

정형된 JSON을 그대로 API 응답이나 삽입 데이터로 돌려주면 들여쓰기의 공백만큼 전송량이 헛되이 늘어납니다. 배포용에는 압축본을 쓰십시오.

문서나 이슈에 붙일 코드 예시를 다듬기

명세서나 버그 보고에 실을 요청 예시·응답 예시를, 들여쓰기가 가지런한 읽기 쉬운 모습으로 고치실 수 있습니다.

다른 형식으로 바꾸기 전의 손질

구문이 올바름을 먼저 확인해 두시면, JSON에서 TypeScript 타입 정의나 JSON에서 XML 같은 변환 도구에 넘기셨을 때 변환 쪽에서 원인을 알기 어려운 오류로 애먹지 않으셔도 됩니다.

JSON에 관한 용어집

JSON
JavaScript Object Notation의 약자로, RFC 8259가 정하는 데이터 교환 형식입니다. 객체·배열·문자열·수·불리언·null의 여섯 가지만으로 이루어지며, 언어를 가리지 않고 읽고 쓸 수 있다는 점에서 웹 API의 표준적인 형식이 되었습니다.
정형(프리티 프린트)
중첩의 깊이에 따라 들여쓰기와 줄바꿈을 넣어 사람이 읽을 수 있는 모습으로 다시 짜는 것입니다. 데이터의 내용은 바뀌지 않고 겉모습만 바뀝니다.
압축(미니파이)
뜻에 상관없는 공백과 줄바꿈을 모두 걷어내어 한 줄로 모으는 것입니다. 바이트 수가 줄어 전송량을 억제할 수 있지만, 사람이 읽기에는 알맞지 않습니다.
검증(밸리데이션)
입력이 JSON의 문법에 맞는지를 확인하는 것입니다. 이 도구는 브라우저의 파서에 해석시키고, 실패했을 때의 오류 메시지를 그대로 보여 줍니다.
이스케이프 시퀀스
문자열 안에 그대로는 쓸 수 없는 글자를, 역슬래시를 써서 나타내는 표기법입니다. 큰따옴표는 \", 줄바꿈은 \n, 탭은 \t로 씁니다.
키의 순서
JSON 자체는 객체의 키에 순서를 정하고 있지 않습니다. 이 도구는 자바스크립트의 객체를 거치므로, "1"이나 "2"처럼 정수로 읽히는 형태의 키만이 오름차순으로 다시 늘어섭니다. 그 밖의 키는 쓰신 순서 그대로 지켜집니다.
UTF-8
RFC 8259가 JSON에 쓰도록 정하고 있는 문자 부호화 방식입니다. 한국어처럼 ASCII 밖의 글자는 한 글자에 여러 바이트를 차지하므로, 글자 수와 바이트 수는 일치하지 않습니다.

자주 묻는 질문

키는 반드시 큰따옴표가 필요하고, 후행 쉼표 불가, undefined·함수·NaN·Infinity는 사용할 수 없습니다.

쓸 수 없습니다. JSON 사양에 주석 구문은 존재하지 않습니다. JSON5나 JSONC가 대안으로 사용됩니다.

RFC 8259에서는 UTF-8이 필수입니다. 상호 운용성 관점에서 UTF-8을 권장합니다.

JSON 사양상 모두 number 타입입니다. 큰 정수는 JavaScript의 MAX_SAFE_INTEGER를 초과하면 정밀도가 손실될 수 있습니다.
툴군

여담 ― JSON이 XML을 이긴 이유

2000년대 초반에는 XML이 주류였지만, 2001년 Douglas Crockford가 JSON을 제창하면서 가볍고·다루기 쉽고·읽기 쉽다는 이유로 2010년대 이후 JSON이 표준이 되었습니다.

같은 데이터에서 JSON이 XML보다 30〜50% 바이트 수가 적은 경우가 많아, 모바일 통신 시대에는 앱 응답 속도에 직결되었습니다.

RFC 8259에서 키 중복은 "SHOULD NOT"이며 금지는 아닙니다. {"a":1,"a":2}는 구문상 유효하지만 동작이 정의되어 있지 않습니다.