Làm dev một thời gian là kiểu gì cũng đụng cảnh này: vừa deploy xong một bản config lên api.dailyvn.vn, mọi thứ chạy khác staging một chút mà không rõ đổi ở đâu; hoặc đang debug tại sao response từ /api/orders/123 ở production khác staging, phải mở 2 tab dán cạnh nhau rồi dò từng dấu ngoặc bằng mắt. Với file JSON vài chục dòng thì còn chịu được, chứ tới vài trăm dòng lồng nhau là mắt mỏi, tay run, và gần như chắc chắn bỏ sót một key nào đó nằm sâu trong object con.

Cái bạn cần không phải là đọc kỹ hơn, mà là so theo đúng cấu trúc dữ liệu thay vì so theo dòng chữ. Dán JSON gốc vào một ô, JSON cần so vào ô kia, để công cụ tự phân loại: key nào thêm mới, key nào bị xoá, key nào đổi giá trị — kèm rõ đường dẫn key để bạn nhảy thẳng vào chỗ cần sửa.

So nhanh 2 file JSON ngay: mở công cụ so sánh JSON, dán JSON gốc vào ô "JSON gốc (trái)", JSON cần so vào ô "JSON so sánh (phải)", kết quả hiện ngay bên dưới. Chạy trên trình duyệt, miễn phí, không cần đăng nhập.

Vì sao so JSON bằng mắt (hay bằng git diff) hay báo sai

Hai file JSON chứa y hệt một dữ liệu vẫn có thể trông "khác nhau hoàn toàn" nếu thụt lề khác, xuống dòng khác, hoặc các key được ghi theo thứ tự khác. Đây chính là lý do git diff hay công cụ so văn bản thông thường hay báo sai: chúng so theo từng dòng chữ, không hiểu JSON là dữ liệu có cấu trúc.

Cách đúng là so theo cấu trúc key–value: parse cả hai JSON, rồi đối chiếu từng key theo đường dẫn của nó (ví dụ user.address.city), bỏ qua chuyện định dạng hay thứ tự, chỉ báo đúng phần dữ liệu thật sự khác.

Cách soCó bắt đúng khác biệt dữ liệu không?Nhược điểmĐọc bằng mắtSai sót nhiều với file dài, lồng nhauChậm, mỏi mắt, dễ bỏ sót key nằm sâuDiff theo dòng (git diff, so văn bản)Báo "khác" cả khi chỉ đổi formatNhạy với thụt lề, xuống dòng, thứ tự keyDiff theo cấu trúc (so sánh JSON)Đúng — chỉ báo phần dữ liệu thật sự đổiCần công cụ hiểu cú pháp JSON

Ngoài phân loại thêm/xoá/thay đổi, công cụ còn xử lý 2 tình huống hay gặp: nếu một trong hai JSON sai cú pháp (thiếu dấu đóng ngoặc, thiếu dấu phẩy...), nó báo lỗi kèm số dòng để bạn sửa nhanh; còn nếu hai JSON giống hệt nhau, nó báo thẳng "Hai JSON giống nhau hoàn toàn" — khỏi phải ngồi đoán xem mình có bỏ sót gì không.

4 tình huống dev hay cần so JSON — và cách làm

Bước 1 — So config trước/sau khi deploy (staging vs production)

Tình huống quen thuộc nhất: bản build chạy đúng ở staging nhưng lên production lại lỗi, và nghi ngờ đầu tiên luôn là config bị lệch. Thay vì mở 2 file .env.json rồi dò từng dòng, dán config staging vào ô trái, config production vào ô phải.

Ví dụ hai bản config trông gần giống nhau:

{
  "API_URL": "https://staging-api.dailyvn.vn",
  "DEBUG": true,
  "RATE_LIMIT": 100,
  "CACHE_TTL": 60
}

so với:

{
  "API_URL": "https://api.dailyvn.vn",
  "DEBUG": false,
  "RATE_LIMIT": 100,
  "CACHE_TTL": 60,
  "MAINTENANCE_MODE": false
}

Kết quả sẽ liệt kê rõ: API_URL và DEBUG thuộc nhóm thay đổi, MAINTENANCE_MODE thuộc nhóm thêm — còn RATE_LIMIT và CACHE_TTL giống nhau nên không bị nêu tên. Nhìn phát biết ngay đâu là chủ ý (đổi URL, tắt debug) và đâu là thiếu sót (quên set MAINTENANCE_MODE bên staging).

Lỗi hay gặp:

  • Dán nguyên file config có dấu phẩy thừa ở cuối hoặc có comment kiểu // ghi chú — chuẩn JSON không hỗ trợ comment, công cụ sẽ báo lỗi cú pháp kèm số dòng. Cách xử lý nhanh: đưa qua công cụ định dạng JSON để phát hiện và sửa lỗi cú pháp trước, rồi mới so.

  • Copy thiếu dấu ngoặc nhọn/vuông ở đầu hoặc cuối khi dán từ terminal — cũng gây lỗi cú pháp tương tự, kiểm tra lại phần đầu/cuối đoạn dán.

Bước 2 — So API response giữa 2 môi trường lúc debug

Khi một tính năng chạy đúng ở môi trường này nhưng sai ở môi trường kia, cách nhanh nhất để khoanh vùng là so response API thật của cả hai. Gọi cùng một endpoint ở hai môi trường, copy response, dán vào công cụ.

Ví dụ response từ GET /api/orders/123:

{
  "orderId": 123,
  "status": "paid",
  "customer": { "name": "Nguyễn Văn A", "phone": "0912xxxxxx" },
  "total": 450000
}

so với response ở môi trường kia:

{
  "orderId": 123,
  "status": "pending",
  "customer": { "name": "Nguyễn Văn A", "phone": "0912xxxxxx" },
  "total": 450000,
  "discount": 0
}

Kết quả chỉ ra đúng đường dẫn key status nằm trong nhóm thay đổi (paid → pending), và discount nằm trong nhóm thêm. Bạn khoanh vùng ngay được nghi phạm là logic tính trạng thái đơn hàng, thay vì phải đọc lại toàn bộ response từ đầu.

Lỗi hay gặp:

  • Thấy hai response "trông khác nhau" chỉ vì thứ tự key khác nhau (server trả field không theo thứ tự cố định) rồi tưởng dữ liệu có vấn đề — thực ra công cụ so theo đường dẫn key chứ không theo thứ tự dòng, nên trường hợp này hoàn toàn không bị báo là khác biệt, bạn không cần lo.

  • Copy response còn dính header HTTP hoặc log dòng đầu (kiểu HTTP/1.1 200 OK) lẫn vào — xoá phần đó đi, chỉ giữ lại đúng phần thân JSON.

Bước 3 — Kiểm tra file locale/i18n xem thiếu key nào (vi.json vs en.json)

Với site đa ngôn ngữ, lỗi hay gặp nhất là thêm key mới cho bản tiếng Việt rồi quên bổ sung bản tiếng Anh (hoặc ngược lại). Dán vi.json vào ô trái, en.json vào ô phải để dò key thiếu.

{
  "checkout": {
    "confirm": "Xác nhận đơn hàng",
    "cancel": "Huỷ đơn"
  }
}

so với:

{
  "checkout": {
    "cancel": "Cancel order"
  }
}

Vì checkout.confirm có ở bên trái (vi.json) nhưng không có ở bên phải (en.json), công cụ xếp nó vào nhóm xoá — đúng nghĩa là "thiếu ở bản so sánh". Nhìn danh sách này là biết ngay bản tiếng Anh còn thiếu key nào cần dịch bổ sung, không phải dò từng dòng trong file JSON i18n cả nghìn key.

Bước 4 — Review payload webhook khi đối tác đổi version

Đối tác thanh toán hay vận chuyển đổi version webhook là chuyện thường, và tài liệu họ gửi đôi khi không liệt kê đủ những gì thật sự đổi. Cách chắc ăn là lấy payload mẫu của version cũ và version mới rồi so trực tiếp.

{
  "event": "payment.success",
  "amount": "450000",
  "orderCode": "DH0012"
}

so với payload version mới:

{
  "event": "payment.success",
  "amount": 450000,
  "currency": "VND",
  "orderCode": "DH0012"
}

Kết quả cho thấy amount thuộc nhóm thay đổi — không chỉ giá trị mà cả kiểu dữ liệu đổi từ chuỗi "450000" sang số 450000, và currency thuộc nhóm thêm. Đây là loại lỗi âm thầm nhất: code cũ parse amount như string, đối tác đổi sang number, nếu không so kỹ rất dễ gây lỗi tính toán mà không có exception nào báo trước.

Lỗi hay gặp:

  • Payload thật của webhook production thường có rất nhiều field lồng nhau (metadata, signature, timestamp...) — dán nguyên khối rất dễ rối mắt khi đọc kết quả. Chỉ nên cắt phần cần so (ví dụ khối data hoặc payment), so đúng phần nghi ngờ thay vì so trọn cả payload.

  • Quên xoá field có giá trị đổi liên tục như timestamp hoặc requestId trước khi so — hai field này lúc nào cũng khác nhau, sẽ tạo nhiễu che mất khác biệt thật sự cần tìm.

Kỳ vọng kết quả: đọc sao cho đúng, mất bao lâu

  • Thời gian: dán xong là có kết quả gần như ngay lập tức, kể cả với JSON vài trăm dòng — không phải chờ xử lý.

  • Cách đọc kết quả: mỗi khác biệt được gắn đúng đường dẫn key (ví dụ customer.address.city) và xếp vào một trong ba nhóm — thêm (có ở bên phải, không có ở bên trái), xoá (có ở bên trái, không có ở bên phải), thay đổi (cùng key nhưng khác giá trị).

  • Khi JSON sai cú pháp: công cụ báo lỗi kèm số dòng cụ thể, bạn sửa xong dán lại là so tiếp được ngay — không cần đoán mò lỗi nằm ở đâu.

  • Khi hai JSON giống hệt nhau: thông báo thẳng "Hai JSON giống nhau hoàn toàn", đỡ mất công đọc lại từ đầu để tự kiểm tra.

Câu hỏi thường gặp (FAQ)

Hai file JSON có cần định dạng giống hệt nhau (thụt lề, khoảng trắng) mới so được không? Không cần. Công cụ so theo cấu trúc key–value, không quan tâm thụt lề, khoảng trắng hay xuống dòng khác nhau như thế nào.

Nếu một trong hai JSON bị lỗi cú pháp thì sao? Công cụ báo lỗi kèm số dòng để bạn sửa nhanh. Nếu chưa chắc lỗi nằm ở đâu, có thể đưa qua công cụ định dạng JSON để tự động phát hiện và format lại trước khi so.

Thứ tự key trong hai JSON khác nhau thì kết quả có bị sai không? Không sai. Việc so được thực hiện theo đường dẫn key, không theo thứ tự xuất hiện, nên đảo thứ tự key hoàn toàn không ảnh hưởng tới kết quả.

Dữ liệu tôi so là YAML chứ không phải JSON thì làm sao? Bạn có thể chuyển qua công cụ chuyển đổi YAML ↔ JSON để đưa cả hai về JSON trước, rồi so như bình thường.

BKNS Tools — bộ công cụ lập trình miễn phí cho dev Việt. So sánh JSON · Định dạng JSON · Chuyển YAML ↔ JSON — không cần đăng nhập.