두 개의 JSON 조각을 붙여 넣고, 포맷팅한 뒤 나란히 비교하세요. 검증, 보기 좋게 출력, 미니파이 기능 내장.
두 개의 JSON 문서를 비교하는 무료 브라우저 내 도구입니다. 왼쪽에 이전 버전, 오른쪽에 새 버전을 붙여 넣으면 차이점이 글자 단위로 빛납니다. 어떤 데이터도 사용자의 컴퓨터를 떠나지 않습니다.
검증에는 브라우저의 네이티브 JSON.parse를 사용합니다. JSON이 한 줄짜리 거대한 미니파이 상태일 때를 위한 Format 버튼, 반대 경우를 위한 Minify 버튼, 그리고 입력하는 동안 문법 오류를 표시하는 라이브 검증이 있습니다.
GitHub PR에서 6,000줄짜리 openapi.json 차이를 노려보며 다운스트림 클라이언트를 망가뜨린 단 하나의 필드를 찾아본 적이 있다면, 이 도구가 그 위치까지 몇 초 안에 데려다 줍니다.
diff는 글자 단위이며, 의미 단위의 후처리로 다듬어져 하이라이트가 임의의 글자가 아니라 의미 있는 덩어리에 떨어지도록 만듭니다. 추가는 오른쪽 패널에서 초록색, 삭제는 왼쪽 패널에서 빨간색으로 표시됩니다.
JSON에는 명세가 짚어 두는 고유한 특성이 있습니다. RFC 8259의 JSON 명세는 객체를 순서가 없는 것으로 정의하므로, 키를 재배열하는 것은 기술적으로 아무 변화도 아니지만 텍스트 diff는 이를 차이로 표시합니다. 우리는 양쪽에 Format 버튼을 제공해 이를 처리합니다. 양쪽을 모두 포맷한 다음 비교하면 순서가 일관되게 됩니다. 더 깊은 구조적 작업이 필요하다면, JSON 변경을 데이터로 기술하는 두 가지 표준 방식인 JSON Patch (RFC 6902)나 더 간단한 JSON Merge Patch 형식 (RFC 7396)을 살펴보세요.
해싱이나 서명을 위해 순서가 중요한 경우 관련 명세는 RFC 8785 (JSON Canonicalization Scheme)입니다. 키를 정렬하고 숫자 표기를 정규화한 뒤 diff를 수행하세요.
두 개의 텍스트 패널, 하나의 diff. 가입도, 업로드도, 서버 왕복도 없습니다.
왼쪽에 이전 JSON, 오른쪽에 새 JSON을 붙여 넣으세요. 또는 양쪽 어느 쪽이든 Upload를 눌러 .json 파일을 직접 불러올 수 있습니다. 도구가 어떻게 동작하는지 먼저 보고 싶다면 Sample 버튼이 양쪽 패널을 작은 예제로 채워 줍니다.
각 패널에서 Format을 눌러 두 칸 들여쓰기로 보기 좋게 출력하세요. 이렇게 하면 공백과 줄바꿈이 정규화되어, diff가 포맷 차이가 아니라 실제 데이터 변경을 강조합니다. JSON이 오류 없이 파싱되면 검증 배지가 초록색으로 바뀝니다.
삭제는 왼쪽에 빨간색 하이라이트로, 추가는 오른쪽에 초록색 하이라이트로 나타납니다. 한쪽을 스크롤하면 다른 쪽도 따라옵니다. 각 헤더의 변경 카운트는 diff가 찾은 별개 편집 개수를 알려 줍니다.
현재 aws iam get-policy-version 출력과 제안된 JSON을 붙여 넣어, 어떤 Action 항목이 추가되었는지, 또는 이전에는 구체적이었던 statement에 누군가 "Resource": "*"를 슬쩍 끼워 넣지 않았는지 정확히 확인하세요. AWS 콘솔은 저장 시 statement를 재정렬하므로 GitHub diff가 오해를 부를 수 있습니다. 여기서 양쪽을 포맷하면 진짜 변경이 분명해집니다.
terraform show -json tfplan이 4 MB 덩어리를 반환하면 눈으로 보는 것은 가망이 없습니다. 오늘의 플랜을 어제 플랜과 비교해, 누군가 리팩터 PR 아래에 추가한 aws_security_group_rule이나 조용히 사라진 lifecycle.ignore_changes 블록을 떠오르게 하세요.
코드 생성기가 paths를 알파벳 순으로 재정렬하면 6,000줄짜리 openapi.json diff는 읽을 수가 없습니다. 양쪽을 포맷하고 비교하면 진짜 변경이 드러납니다. CreateOrderRequest에 추가된 required 필드, 또는 스키마가 조용히 string에서 string | null로 바뀐 200 응답 같은 것들이요.
package-lock.json 충돌을 해결한 뒤, 해결한 파일을 main의 lockfile과 비교해 전이적 다운그레이드를 잡아 내세요. npm은 같은 semver 범위를 머신마다 서로 다른 정확한 버전으로 해결하기도 하며, 이것이 "내 컴퓨터에서는 되는데 CI에서는 깨진다"의 진짜 원인입니다. 각 필드의 의미는 package-lock.json 문서를 참고하세요.
스테이징과 프로덕션에서 GET /my-index/_mapping을 가져와 둘 다 diff에 넣으세요. 프로덕션에는 스테이징이 지난 스프린트에 "keyword"로 마이그레이션한 필드에 여전히 "type": "text"가 남아 있을 수 있고, 이것이 집계 쿼리가 프로덕션에서는 아무것도 반환하지 않고 로컬에서는 동작하는 이유입니다. 매핑은 다섯, 여섯 단계로 중첩되며 텍스트 diff는 이를 노이즈에 묻어 버립니다.
Playwright 테스트가 로컬에서는 통과하고 CI에서는 실패하면, 테스트가 실제로 본 JSON 응답 본문을 캡처해 리포지토리의 fixture와 비교하세요. 종종 아무도 고정해 두지 않은 createdAt 타임스탬프나 traceId 필드가 원인이고, 구조적 diff는 포맷된 텍스트 벽에 빠뜨리는 대신 문제의 키를 한눈에 보여 줍니다.
이 도구가 가장 자주 드러내는 파싱 엣지 케이스에 대한 짧은 치트 시트입니다. 모두 JSON 명세에 근거합니다.
| Topic | What this tool does |
|---|---|
| 객체 키 순서 | 명세상 순서 없음. {"a":1,"b":2}는 {"b":2,"a":1}과 동일합니다. 비교 전 정규화에는 Sort keys를 사용하세요. |
| 배열 순서 | 순서 있음. [1,2,3]은 [3,2,1]과 같지 않습니다. 사용 사례에서 순서가 중요하지 않다면 수동으로 정렬하세요. |
| 끝쉼표 | 허용되지 않음. { "a": 1, }는 표준 JSON에서 파싱 오류입니다. 슈퍼셋인 JSON5/JSONC에서는 허용됩니다. 먼저 제거하세요. |
| 주석 | 허용되지 않음. // 이런 것은 파싱 오류입니다. JSON5와 JSONC는 받아들이지만, 이 도구는 RFC 8259의 엄격한 문법을 따릅니다. |
| 숫자 | 64비트 IEEE 754 부동소수점으로 파싱됩니다. 0.1 + 0.2 = 0.30000000000000004. 2^53 − 1 이상의 정수는 정밀도를 잃습니다. 스노우플레이크 ID는 문자열로 저장하세요. |
| 중복 키 | 명세는 정의되지 않은 동작이라고 합니다. 대부분의 파서는 마지막 등장을 유지합니다. diff는 모두 보여 주며, 이는 보통 설정 파일을 감사할 때 원하는 동작입니다. |
| 인코딩 | UTF-8 전용. RFC 8259는 문서 시작에 UTF-8 BOM을 두는 것을 금지합니다. 일부 파서는 받아들이지만 명세는 그렇지 않습니다. |
| Null 대 누락 | 값이 null인 키는 존재합니다. 누락된 키는 부재합니다. JSON 표현이 없는 JavaScript의 undefined와 다릅니다. |
아니요. diff는 전적으로 브라우저에서 실행됩니다. 어떤 것도 서버로 전송되거나 로깅되거나 저장되지 않습니다. 내부 API 응답이나 IAM 정책을 붙여 넣고 탭을 닫으면 어디에도 사본이 남지 않습니다. 확인하려면 DevTools를 열어 Network 탭으로 전환하고 지켜보세요. 비교할 때 외부로 나가는 요청이 전혀 없습니다.
네, 둘 다 그렇습니다. 텍스트 diff는 줄 단위로 글자를 비교하므로, 데이터가 동일하더라도 재포맷, 키 재정렬, 공백 변경이 차이로 나타납니다. 먼저 양쪽 패널에서 Format 버튼을 누르면 diff가 실제 데이터 변경에 집중합니다. 키 순서를 완전히 무시하는 구조적 비교가 필요하면, 비교 전에 양쪽 키를 정렬하세요.
객체 키는 중요하지 않습니다. JSON 명세는 객체를 순서가 없는 것으로 정의하므로, {"a":1,"b":2}와 {"b":2,"a":1}은 같은 데이터를 나타냅니다. 글자 단위 diff는 여전히 재정렬을 표시하므로 Format 버튼이 의미가 있습니다. 배열은 다릅니다. [1,2,3]과 [3,2,1]은 동일하지 않은데, JSON에서 배열 순서는 의미가 있기 때문입니다.
IEEE 754 부동소수점 때문입니다. 0.1 + 0.2는 실제로 0.30000000000000004이고, JSON.parse는 숫자를 64비트 부동소수점으로 읽습니다. 큰 정수도 같은 한계에 부딪칩니다. 2^53 - 1(9007199254740991)을 넘어가면 정밀도를 잃기 때문에 Twitter 스타일 스노우플레이크 ID는 라운드트립되지 않습니다. 정밀도가 중요하다면 문자열로 저장하세요.
표준 JSON은 둘 다 허용하지 않습니다. { "a": 1, }이나 // 주석은 파싱 오류를 일으킵니다. 그것은 슈퍼셋인 JSON5 또는 JSONC(VS Code가 settings.json에 사용하는 형식)입니다. 먼저 주석과 끝쉼표를 제거하세요. 우리는 의도적으로 RFC 8259의 엄격한 문법을 따르며, 그래야 diff가 사용자의 API가 실제로 받아들이는 것과 일치합니다.
몇 MB 정도까지는 1초 이내로 잘 동작합니다. 10 MB를 넘기면 브라우저가 부담을 느끼기 시작하는데, 주된 이유는 diff 계산이 아니라 렌더링이 비싸지기 때문입니다. 50 MB 이상의 익스포트라면, 먼저 jq로 양쪽을 관심 있는 하위 트리로 필터링한 뒤 그것을 붙여 넣으세요.
여러분의 JSON은 결코 브라우저를 떠나지 않습니다. 파서, 포맷터, diff 모두 사용자의 머신에서 로컬로 동작합니다. 입력에 대한 분석도 없고, 로그도 없으며, "도움이 되는" 클라우드 왕복도 없습니다. 파싱은 브라우저 네이티브 JSON.parse를 사용하고, 우리가 따르는 JSON 명세는 RFC 8259입니다.