JSON 유효성 검사기 및 포매터

JSON 유효성 검사기 및 포매터는 JSON의 구문이 올바른지 검사하고, 유효한 콘텐츠의 구조를 쉽게 읽을 수 있도록 정리해 주는 무료 도구입니다.

JSON 유효성 검사와 포매팅은 어떤 작업을 하나요?

JSON 유효성 검사는 입력 내용이 JSON 문법을 따르는지 확인합니다. 포매팅은 유효한 객체와 배열에 일관된 공백과 들여쓰기를 적용합니다. API 응답을 디버깅하거나, 배포 전에 설정을 점검하거나, 외부에서 받은 압축된 데이터를 읽을 때 유용합니다.

JSON 구문은 JavaScript 객체 리터럴보다 엄격합니다. 속성 이름에는 큰따옴표를 사용해야 하고, 문자열에는 작은따옴표를 사용할 수 없으며, 객체나 배열의 마지막 항목 뒤에 쉼표를 붙여서도 안 됩니다. 주석, undefined, NaN, Infinity 역시 JSON 명세에 포함되지 않습니다.

이 도구는 서버에서 PHP의 json_decode 함수를 사용합니다. 입력한 내용은 HTTPS를 통해 서버로 전송되며 저장되지 않습니다. 다만 데이터가 기기 외부로 전송되므로, 조직의 데이터 처리 규정상 외부 서버 전송이 허용되지 않는다면 비밀번호, 액세스 토큰, 개인정보를 삭제한 뒤 사용하세요.

JSON을 검사하고 보기 좋게 정리하려면 어떻게 하나요?

콘텐츠를 JSON 필드에 붙여넣고 도구를 실행하세요. 정확한 결과를 얻으려면 로그 한 줄에서 객체 일부만 복사하지 말고, 완전한 JSON 값 하나를 입력해야 합니다.

1. 앞뒤에 붙은 콘솔 레이블을 제외하고 원본 응답, 설정 블록 또는 다른 JSON 값을 복사하세요.
2. 따옴표와 이스케이프 문자를 그대로 유지하여 JSON 필드에 붙여넣으세요.
3. 유효성 검사를 실행한 뒤 포맷된 결과 또는 표시된 오류를 확인하세요.
4. 검사에 실패하면 가장 먼저 보이는 구문 문제부터 수정한 다음 다시 실행하세요. 따옴표 하나만 빠져도 그 뒤의 여러 문자가 잘못 해석될 수 있습니다.

JSON 토큰 사이에 허용되는 공백 문자 4개는 스페이스(U+0020), 탭(U+0009), 줄 바꿈(U+000A), 캐리지 리턴(U+000D)입니다. 이 문자는 데이터에 영향을 주지 않으므로 추가하거나 삭제해도 됩니다. 반면 따옴표로 묶인 문자열 안의 공백은 데이터이므로 변경하면 안 됩니다. 문자열 안의 문장 부호도 그대로 유지되지만, 따옴표, 백슬래시, 제어 문자에는 적절한 이스케이프 시퀀스가 필요합니다.

유효성 검사 결과는 어떻게 해석하나요?

검사에 성공했다면 PHP가 입력 내용을 JSON으로 디코딩할 수 있다는 뜻입니다. 실패했다면 파서가 입력 내용을 하나의 완전하고 유효한 JSON 값으로 해석하지 못했다는 뜻입니다. 유효한 JSON을 포맷하면 객체와 배열의 중첩 구조와 경계가 분명하게 드러납니다.

흔한 실패 원인은 다음과 같습니다.

• } 또는 ] 앞에 붙은 후행 쉼표
• {name: "Ada"}처럼 따옴표로 묶지 않은 속성 이름
• 작은따옴표로 묶은 문자열
• 속성이나 배열 요소 사이에 빠진 쉼표
• 문자열 안에서 이스케이프 처리하지 않은 큰따옴표 또는 백슬래시
• 완성되지 않은 객체, 배열 또는 문자열
• 유효하지 않은 UTF-8 입력 또는 문자열 안의 원시 제어 문자
• 01이나 -01처럼 정수 부분에 불필요한 선행 0이 있거나, NaN처럼 JSON에 없는 값을 사용한 경우

빈 필드는 유효한 JSON이 아닙니다. 반면 42, true, null, "hello"처럼 값 하나만 있어도 객체나 배열은 아니지만 유효한 JSON입니다. 중첩 수준이 지나치게 깊은 콘텐츠는 디코더의 중첩 한도를 초과할 수도 있습니다.

구문 유효성 검사만으로는 데이터가 API 계약에 부합하는지 확인할 수 없습니다. 애플리케이션이 숫자를 요구하는 곳에 문자열이 들어 있거나, 필수 속성이 누락되었거나, 허용되지 않는 날짜 형식을 사용해도 문서 자체는 유효한 JSON일 수 있습니다. 이러한 요구사항은 JSON Schema 또는 애플리케이션 수준의 검사로 확인하세요.

JSON 예제로 살펴보기

유효한 압축 입력:

{"name":"Ada","active":true,"roles":["admin","editor"]}

포맷된 결과에서는 속성과 배열 요소가 각각 별도의 들여쓰기 수준에 표시됩니다. 각 값의 형식은 문자열, 불리언, 배열로 그대로 유지됩니다. 포매팅은 표시 방식만 바꾸며 기본 데이터 유형은 변경하지 않습니다.

후행 쉼표가 있는 잘못된 입력:

{"name":"Ada","active":true,}

JSON에서는 마지막 속성 뒤에 쉼표를 허용하지 않으므로 검사에 실패합니다. 해당 쉼표를 삭제하면 유효한 객체가 됩니다.

입력이 유효한 UTF-8이라면 악센트가 있는 문자와 비라틴 문자도 JSON 문자열에 직접 넣을 수 있습니다. 예를 들어 {"city":"Zürich","greeting":"こんにちは"}는 유효합니다. \u00fc 같은 JSON 이스케이프 표기법도 특정 Unicode 문자를 나타내는 유효한 방식입니다. 다만 기본 다국어 평면 밖의 문자에는 서로게이트 쌍이 필요합니다.

JSON 포매팅이 필요하지 않은 경우는 언제인가요?

JSON을 기계만 읽고 사람이 직접 확인하거나 버전 관리에서 검토할 계획이 없다면 포매팅할 필요가 없습니다. JSON에 들여쓰기와 줄 바꿈을 추가하면 전송되는 바이트 수가 늘어나므로, 운영 환경의 응답은 일반적으로 압축된 형태로 전송됩니다.

이미 압축된 JSON을 다시 압축해도 얻을 수 있는 이점은 거의 없습니다. 압축을 반복해도 고정된 속성 이름이나 문자열 값을 더 짧게 만들 수 없으며, 이러한 값을 변경하면 데이터 자체가 달라집니다. JSON 데이터가 아니라 배포용 JavaScript를 처리하려면 JS 압축기가 더 적합합니다.

포매팅은 디버깅, 코드 검토, 배포 전 점검 과정에서 JSON 구조나 값을 살펴볼 때 가장 유용합니다. 서로 맞지 않는 중첩 구조가 드러나고, 큰 배열을 훑어보기 쉬워지며, 설정을 Git에 커밋할 때 변경 사항도 더 깔끔하게 비교할 수 있습니다. 다만 잘못된 JSON을 자동으로 복구하거나, 모호한 조각이 원래 무엇을 의미했는지 판단해 주지는 않습니다.

자주 묻는 질문

JSON에 주석을 넣어도 되나요?

아니요. 표준 JSON에는 주석 구문이 없으므로 // comment와 /* comment */를 넣으면 유효성 검사에 실패합니다. 설정 파일에 주석이 필요하다면 주석을 지원하는 형식을 사용하거나, 엄격한 JSON 파서로 처리하기 전에 주석을 삭제하세요.

속성 이름이 중복되면 오류가 나나요?

반드시 그렇지는 않습니다. JSON 명세에서는 객체 안의 멤버 이름이 고유해야 한다고 규정하지만, 파서가 중복 이름을 항상 구문 오류로 처리하는 것은 아닙니다. PHP 디코딩은 일반적으로 뒤에 나온 값을 유지하므로, 모든 항목을 보존해야 한다면 유효성 검사 전에 중복 여부를 확인하세요.

JSON Lines 파일도 검사할 수 있나요?

하나의 JSON 문서로는 검사할 수 없습니다. NDJSON이라고도 하는 JSON Lines는 각 줄에 별도의 JSON 값을 담지만, 일반 JSON 파서는 최상위 값 하나를 기대합니다. 각 줄을 따로 검사하거나 레코드를 하나의 JSON 배열로 변환하세요.

JSON 객체의 속성 순서가 중요한가요?

애플리케이션은 JSON 객체의 속성 순서에 의존해서는 안 됩니다. 배열에는 순서가 있지만 객체는 이름이 있는 멤버의 모음을 나타냅니다. 다른 파서나 직렬화 도구는 해당 멤버를 다른 순서로 출력할 수 있습니다. 순서 자체에 의미가 있다면 값을 배열에 넣으세요.

올바르게 보이는 JSON 파일이 왜 검사에 실패하나요?

눈에 보이지 않는 바이트 순서 표시, 잘못된 UTF-8 또는 이스케이프 처리되지 않은 제어 문자 때문에 겉보기에는 올바른 데이터도 검사에 실패할 수 있습니다. 터미널에서 복사할 때 상태 레이블이나 타임스탬프 같은 접두사가 함께 들어가기도 합니다. 원시 바이트를 확인하거나 인코딩과 제어 문자를 표시할 수 있는 편집기에서 파일을 여세요.

마지막 점검

수정한 JSON을 배포하기 전에 화면에 보이는 값뿐 아니라 데이터 유형도 비교하고, 이스케이프 시퀀스가 바뀌지 않았는지 확인하세요. 또한 해당 데이터를 사용하는 애플리케이션이나 스키마 유효성 검사를 실행하세요. 외부에서 받은 데이터를 진단할 때는 포매팅 때문에 오류의 원인이 가려지지 않도록 원본 응답의 수정하지 않은 사본을 보관하세요.