객체 키 순서가 다르면 차이로 잡히나요?

아닙니다. 비교 전에 키 정렬을 한 번 거치므로 의미상 같은 객체는 차이가 0 입니다.

배열 순서는 어떻게 처리되나요?

배열은 순서가 의미를 갖는 자료구조라 인덱스 위치 기준 비교입니다. `[1,2,3]` vs `[3,2,1]` 은 세 자리 모두 차이로 나타납니다.

파싱 단계에서 에러 메시지가 노출됩니다. 먼저 json-formatter 로 양쪽 JSON 유효성을 검증한 뒤 붙여 넣는 것이 안전합니다.

예시

좌: {"name":"yutils","version":"0.1.0","tools":50}
우: {"name":"yutils","version":"0.2.0","tools":55,"new":true}

  "name": "yutils"
- "version": "0.1.0"
+ "version": "0.2.0"
- "tools": 50
+ "tools": 55
+ "new": true

키 정렬을 적용한 뒤 비교하므로 객체 키 순서가 달라도 의미상 같은 JSON 은 차이로 잡히지 않습니다. 배열은 인덱스 위치 기준 비교.

사용법 / 자주 묻는 질문

Q.객체 키 순서가 다르면 차이로 잡히나요?: A.아닙니다. 비교 전에 키 정렬을 한 번 거치므로 의미상 같은 객체는 차이가 0 입니다.
Q.배열 순서는 어떻게 처리되나요?: A.배열은 순서가 의미를 갖는 자료구조라 인덱스 위치 기준 비교입니다. `[1,2,3]` vs `[3,2,1]` 은 세 자리 모두 차이로 나타납니다.
Q.유효하지 않은 JSON 입력은 어떻게 되나요?: A.파싱 단계에서 에러 메시지가 노출됩니다. 먼저 json-formatter 로 양쪽 JSON 유효성을 검증한 뒤 붙여 넣는 것이 안전합니다.

재미있는 사실

JSON Patch (RFC 6902, 2013) 는 JSON 문서의 변경을 명확히 표현하는 표준 — 6개 연산 (add / replace / remove / move / copy / test) 의 배열 형태. HTTP PATCH 메서드 (RFC 5789) 의 본문 형식으로 가장 잘 쓰여요.
RFC 6902 (2013)
JSON Merge Patch (RFC 7396, 2014) 는 다른 접근 — 새 JSON 문서 자체를 patch 로 사용. `null` 이 삭제 신호, 객체는 재귀 merge. 직관적이지만 'null 명시 X' 같은 한계가 있어 JSON Patch (6902) 와 용도가 갈립니다.
RFC 7396 (2014)
두 표준 차이 — 6902 는 path-based 라 표현력 강함 (배열 인덱스 조작·test 가능), 7396 은 recursive merge 라 단순함. 같은 작업을 한 표준은 `[{op:"remove", path:"/a/b"}]`, 다른 표준은 `{a: {b: null}}`. API 마다 선택이 다른 이유.
Wikipedia — JSON Patch