JSON vs JavaScript 객체 리터럴
JSON은 JavaScript 객체 리터럴과 비슷해 보이지만, 더 작고 더 엄격한 데이터 포맷이며 실행 가능한 값을 포함하지 않습니다.
짧은 버전
JavaScript 객체 리터럴은 소스 코드이고, JSON은 데이터 교환 포맷입니다. 겹치는 부분이 헷갈릴 정도로 많지만 규칙은 다릅니다: JSON의 키와 문자열은 큰따옴표여야 하고, JSON에는 주석이 없으며, JSON은 함수・undefined・NaN・Infinity・Date 객체・정규식을 표현할 수 없습니다.
유효한 JSON 값
JSON 문서에는 객체, 배열, 문자열, 숫자, 불리언, null이 올 수 있습니다. 문자열은 큰따옴표여야 합니다. 객체의 키도 큰따옴표 문자열이어야 합니다. 숫자에는 16진 표기, NaN, Infinity, 숫자 구분자처럼 JavaScript에만 있는 형태를 쓸 수 없습니다.
- 유효한 JSON 문자열: "hello"
- 유효한 JSON 불리언: true
- 유효한 JSON null: null
- 유효한 JSON 객체 키: "name"
JavaScript는 유효하지만 JSON은 무효
{ name: 'Ada', active: true, createdAt: new Date(), onSave() { return true }, tags: ['dev',], }
유효한 JSON 버전
{ "name": "Ada", "active": true, "createdAt": "2026-05-13T00:00:00.000Z", "tags": ["dev"] }
API가 JavaScript처럼 보이는 데이터를 거부하는 이유
API 서버는 보통 요청 본문을 JavaScript 엔진이 아닌 JSON 파서로 파싱합니다. 이는 보안과 상호운용성을 위한 설계입니다: 어떤 언어든 코드를 실행하지 않고 같은 데이터를 파싱할 수 있습니다. 본문에 주석, 메서드, undefined, new Date()가 포함되면 서버는 그것을 순수 데이터로 안전하게 다룰 수 없습니다.
안전하게 변환하는 방법
실행 가능하거나 언어 고유의 값을 일반 데이터로 바꾸세요. 날 짜는 문자열로, 누락된 값은 null 또는 키 생략으로, 주석은 문서로 옮기고, 함수는 전략 이름이나 타입 값 같은 명시적 데이터 필드로 표현하세요.
JSON 수리 가이드
토픽 허브
- JSON Parse Errors: Read the Message, Jump to the Fix
- Fix Invalid JSON: From 'What's Wrong' to a Clean File
- JSON Formatter, Validator, Viewer: Pick the Right Tool
- Repair LLM JSON Output: Handling Almost-JSON from AI
- Privacy: JSON Tools That Don't Leave Your Browser
- JSON Interop: YAML, CSV, XML, JWT, Schema
구체적인 가이드
- Base64 문자열 디코드 방법 (그리고 JWT 페이로드)
- URL 인코딩: 쿼리 파라미터와 경로를 퍼센트 인코드하기
- YAML을 JSON으로 변환하기 (그리고 들여쓰기 오류 피하기)
- JSON을 CSV로 변환: 객체 배열을 펴기
- JSON을 XML로 변환: 루트, 속성, 배열
- JSON을 문자열 리터럴로 이스케이프하기 (그리고 이중 인코드된 JSON 디코드)
- JSON의 후행 쉼표 고치기
- JSON의 작은따옴표 고치기
- JSON의 따옴표 없는 키 고치기
- LLM이 만든 JSON 고치기
- JSON 파싱 오류 “Expected Property Name” 고치기
- API 요청 전에 JSON 검증하기
- JSON 포맷터 vs JSON Repair
- JSON Unexpected Token 오류 고치기
- JSON에서 JavaScript 객체 변환기