온라인 JSON 코드 정렬
API 응답, 설정 파일, 로그 한 줄을 붙여 넣고 편하게 읽어 보세요. 객체와 배열에 깊이별 들여쓰기를 적용하고 키를 줄별로 표시하며 결과에 구문 강조를 제공합니다.
JSON이 압축된 상태로 전달되는 이유
JSON은 API에서 기본적으로 쓰이는 데이터 형식이며, API는 가독성보다 전송 바이트 수를 우선합니다. REST 엔드포인트나 GraphQL 서버의 응답은 공백 없이 직렬화될 수 있습니다. 네트워크에는 적합하지만 사람이 읽기에는 불편합니다. 도구가 저장소에 기록한 설정 파일, 구조화된 로그 한 줄, 페이지에 삽입된 JSON-LD 블록, 개발자 도구의 네트워크 탭에서 복사한 데이터도 마찬가지입니다.
정렬하면 구조가 명확해집니다
들여쓰기가 적용된 JSON에서는 구조에 관한 질문의 답을 바로 찾을 수 있습니다. 객체가 얼마나 깊은지, 필드가 객체의 배열인지 배열의 객체인지, 값이 있어야 할 키가 null인지, 한 레코드가 어디서 끝나고 다음 레코드가 시작하는지 쉽게 보입니다. 정렬된 데이터에서는 누락되거나 오타가 있는 키를 빠르게 찾을 수 있지만 한 줄로 된 데이터에서는 결국 스크립트를 작성하게 되기 쉽습니다. 실무에서는 알고 있는 레코드 식별자부터 찾는 것이 좋습니다. 해당 값을 찾고 이를 포함한 객체를 살펴본 뒤 관련 키를 애플리케이션이 기대하는 규격과 비교하세요. 애플리케이션에서 서로 다르게 처리하는 경우가 많으므로 키 누락, 명시적인 null, 빈 배열을 구별하세요. 정렬하면 이 차이가 잘 보이지만 비즈니스 규칙을 검사하거나 모든 중복 키 문제를 감지하거나 API 계약을 검증하지는 않습니다. 의심스러운 부분을 찾은 뒤에는 애플리케이션 테스트와 스키마 검증으로 확인하세요.
유효하지 않은 JSON은 즉시 잡아냅니다
입력은 출력되기 전에 먼저 파싱되어야 하므로, 정렬은 가장 빠르게 해 볼 수 있는 유효성 검사이기도 합니다. 후행 쉼표, 작은따옴표로 감싼 문자열, 값 안의 이스케이프되지 않은 따옴표, 잘린 응답이 있으면 파싱이 멈추고 결과 대신 오류가 표시됩니다. 디버깅하던 API 응답이 중간에 끊겼다는 사실이나 설정 파일에 쉼표가 하나 더 들어갔다는 사실을 이렇게 알게 되는 경우가 아주 많습니다.
JSON, JSON Lines, JSONP의 차이
이 페이지는 JSON 문서 하나를 정렬합니다. 입력이 한 줄에 JSON 객체가 하나씩 들어 있는 로그 파일이라면 파일 전체가 아니라 살펴보려는 줄만 따로 정렬하세요. 파일 전체는 하나의 유효한 문서가 아니기 때문입니다. 그리고 응답이 데이터를 감싼 함수 이름으로 시작한다면 그것은 JSON이 아니라 JSONP이며, 이 도구가 가끔 페이로드를 JavaScript로 감지하는 이유가 바로 이것입니다. 이 경우에는 감지가 맞으며, JavaScript로 정렬해도 충분히 읽기 쉬운 결과를 얻을 수 있습니다.
자주 묻는 질문
JSON 유효성도 검사하나요?
사실상 그렇습니다. 문서는 정렬되기 전에 먼저 파싱되어야 하므로 문법 오류가 하나라도 있으면 처리가 멈추고 결과 대신 오류가 보고됩니다. 페이로드의 형식이 올바른지 확인하는 가장 빠른 방법입니다.
키 순서는 유지되나요?
포매터는 객체 키를 의도적으로 재정렬하지 않으며 입력 구조를 읽기 쉽게 만드는 것이 목적입니다. 서식과 표현 방식이 바뀔 수 있으므로 정확한 텍스트가 중요하다면 원본을 보관하세요. 키 순서만으로 데이터가 애플리케이션에서 기대하는 스키마와 일치하는지 판단할 수도 없습니다.
매우 큰 API 응답도 정렬할 수 있나요?
실제로 처리할 수 있는 범위는 브라우저의 사용 가능한 메모리와 처리 성능에 달려 있습니다. 큰 응답은 정렬과 구문 강조 중 탭을 느리게 하거나 멈추게 할 수 있으며, 지원 크기를 보장하지 않습니다. 큰 응답에서 레코드 하나를 조사한다면 더 작은 완전한 객체나 배열부터 사용하세요.