Lim inn, formater og sammenlign to JSON-utdrag side om side. Validering, pretty-print og minify innebygd.
Et gratis verktøy i nettleseren for å sammenligne to JSON-dokumenter. Lim inn en gammel versjon til venstre, den nye til høyre, og forskjellene lyser opp tegn for tegn. Ingenting forlater maskinen din.
Det bruker nettleserens innebygde JSON.parse til validering. Det er en Format-knapp når JSON-en din er én diger minifisert linje, en Minify-knapp for det motsatte tilfellet, og live validering som flagger syntaksfeil mens du skriver.
Hvis du noen gang har stirret på en 6 000 linjers openapi.json-diff i en GitHub-PR og prøvd å finne det ene feltet som ødela en downstream-klient, er dette verktøyet som tar deg dit på sekunder.
Diffen er på tegnnivå, og deretter ryddet opp med semantisk etterbehandling slik at uthevingene lander på meningsfulle biter i stedet for tilfeldige tegn. Innsettinger vises i grønt i høyre rute, slettinger i rødt i venstre.
JSON har sine egne særegenheter som spesifikasjonen påpeker. JSON-spesifikasjonen i RFC 8259 definerer objekter som uordnede, så å omorganisere nøkler er teknisk sett en null-operasjon selv om en tekst-diff vil flagge det. Vi håndterer det ved å gi deg en Format-knapp på hver side: formater begge, sammenlign deretter, og rekkefølgen blir konsistent. For dypere strukturelt arbeid, se JSON Patch (RFC 6902) eller det enklere JSON Merge Patch-formatet (RFC 7396), som er de to standardmåtene å beskrive en JSON-endring som data.
Når rekkefølge betyr noe for hashing eller signering, er RFC 8785 (JSON Canonicalization Scheme) den relevante spesifikasjonen. Sorter nøkler, normaliser tallformatering, og kjør så diff.
To tekstruter, én diff. Ingen registrering, ingen opplasting, ingen serverrundtur.
Lim inn den gamle JSON-en til venstre, den nye JSON-en til høyre. Eller klikk Upload på en av sidene for å laste inn en .json-fil direkte. Sample-knappen fyller begge rutene med et lite eksempel hvis du først vil se verktøyet i aksjon.
Klikk Format i hver rute for å pretty-printe med to mellomroms innrykk. Dette normaliserer mellomrom og linjeskift slik at diffen fremhever faktiske dataendringer, ikke formateringsforskjeller. Valideringsmerket blir grønt når JSON-en din parses rent.
Slettinger vises med rød utheving til venstre, innsettinger med grønn utheving til høyre. Rull på en side, så følger den andre med. Endringstellingene i hver overskrift forteller deg hvor mange distinkte redigeringer diffen fant.
Lim inn gjeldende utdata fra aws iam get-policy-version mot den foreslåtte JSON-en for å se nøyaktig hvilke Action-oppføringer som er lagt til, eller om noen har sneket "Resource": "*" inn i en tidligere spesifikk setning. AWS-konsollen omorganiserer setninger ved lagring, noe som gjør en GitHub-diff villedende; formater begge sider her, og den faktiske endringen blir tydelig.
Når terraform show -json tfplan returnerer en 4 MB-blob, er det håpløst å se på det med øynene. Sammenlign dagens plan mot gårsdagens for å få fram aws_security_group_rule som noen la til under en refactor-PR, eller lifecycle.ignore_changes-blokken som stille forsvant.
En 6 000 linjers openapi.json-diff er uleselig når en kodegenerator omorganiserer paths alfabetisk. Formater begge sider, sammenlign, og den faktiske endringen kommer fram: et required-felt lagt til CreateOrderRequest, eller en 200-respons hvis skjema stille byttet fra string til string | null.
Etter at du har løst en konflikt i package-lock.json, sammenlign den løste filen din med lockfilen i main for å fange en transitiv nedgradering. npm løser noen ganger det samme semver-intervallet til ulike eksakte versjoner på tvers av maskiner, noe som er den faktiske årsaken til "fungerer på min maskin, feiler i CI". Les package-lock.json-dokumentasjonen for hva hvert felt betyr.
Hent GET /my-index/_mapping fra staging og prod, slipp begge i diffen. Prod kan fortsatt ha "type": "text" på et felt som staging migrerte til "keyword" forrige sprint, og det er derfor aggregation-spørringen ikke returnerer noe i prod og fungerer lokalt. Mappinger nestes fem eller seks nivåer dypt, og en tekst-diff begraver dette i støy.
Når en Playwright-test består lokalt og feiler i CI, fang JSON-responskroppen testen faktisk så og sammenlign den med fixturen i repoet ditt. Ofte er det et createdAt-tidsstempel eller et traceId-felt som ingen pinnet, og den strukturelle diffen gjør den skyldige nøkkelen åpenbar i stedet for å dumpe deg i en vegg av formatert tekst.
Et kort jukseark for parse-grensetilfellene som dette verktøyet får fram oftest. Alt er forankret i JSON-spesifikasjonen.
| Topic | What this tool does |
|---|---|
| Objektnøkkelrekkefølge | Uordnet ifølge spesifikasjonen. {"a":1,"b":2} er lik {"b":2,"a":1}. Bruk Sorter nøkler for å normalisere før diffing. |
| Array-rekkefølge | Ordnet. [1,2,3] er ikke lik [3,2,1]. Sorter manuelt hvis rekkefølge ikke betyr noe for use casen din. |
| Etterfølgende komma | Ikke tillatt. { "a": 1, } er en parsefeil i standard JSON. Tillatt i JSON5/JSONC, som er supersett — fjern dem først. |
| Kommentarer | Ikke tillatt. // slik som dette er en parsefeil. JSON5 og JSONC aksepterer dem; dette verktøyet følger den strenge RFC 8259-grammatikken. |
| Tall | Parses som 64-bits IEEE 754 floats. 0.1 + 0.2 = 0.30000000000000004. Heltall over 2^53 − 1 mister presisjon; lagre snowflake-ID-er som strenger. |
| Duplikate nøkler | Spesifikasjonen kaller det udefinert atferd. De fleste parsere beholder siste forekomst. Diffen vil vise alle, noe som vanligvis er det du vil ha når du reviderer konfigurasjonsfiler. |
| Koding | Kun UTF-8. RFC 8259 forbyr en UTF-8 BOM i starten av dokumentet; noen parsere aksepterer det likevel, men spesifikasjonen gjør ikke det. |
| Null vs manglende | En nøkkel med verdien null er til stede. En manglende nøkkel er fraværende. Forskjellig fra JavaScript's undefined, som ikke har noen JSON-representasjon. |
Nei. Diffen kjører helt i nettleseren din. Ingenting sendes til en server, logges eller lagres. Lim inn et internt API-svar eller en IAM-policy og lukk fanen; det er ingen kopi igjen. For å verifisere, åpne DevTools, bytt til Network-fanen og se på — det er ingen utgående forespørsler når du sammenligner.
Ja, begge gjør det. En tekst-diff sammenligner tegn linje for linje, så omformatering, omorganiserte nøkler eller mellomroms-endringer dukker opp som forskjeller selv når dataene er identiske. Klikk på Format-knappen i begge rutene for å pretty-printe først, så fokuserer diffen på faktiske dataendringer. For en fullstendig strukturell sammenligning som ignorerer nøkkelrekkefølgen, sorter nøklene på begge sider før du sammenligner.
For objektnøkler nei — JSON-spesifikasjonen sier at objekter er uordnede, så {"a":1,"b":2} og {"b":2,"a":1} representerer de samme dataene. En tegn-diff vil likevel flagge omorganiseringen, og det er derfor Format-knappen er viktig. Arrayer er annerledes: [1,2,3] og [3,2,1] er ikke like fordi array-rekkefølge er meningsfull i JSON.
På grunn av IEEE 754 flyttall. 0.1 + 0.2 er faktisk 0.30000000000000004, og JSON.parse leser tall som 64-bits floats. Store heltall treffer samme grensen: alt over 2^53 - 1 (9007199254740991) mister presisjon, så en snowflake-ID i Twitter-stil overlever ikke en rundtur. Hvis presisjon betyr noe, lagre dem som strenger.
Standard JSON tillater ingen av delene. { "a": 1, } eller // kommentar gir deg en parsefeil. Det er JSON5 eller JSONC (formatet VS Code bruker for settings.json), som er et supersett. Fjern kommentarene og de etterfølgende kommaene først. Vi følger den strenge RFC 8259-grammatikken bevisst slik at diffen samsvarer med det API-et ditt faktisk aksepterer.
Opptil noen få MB er greit, under sekundet. Forbi 10 MB begynner nettleseren å kjenne på det, mest fordi det er rendering av diffen (ikke beregning av den) som blir dyrt. For 50 MB+ eksporter, filtrer begge sider til undertreet du bryr deg om med jq først, og lim deretter inn det.
JSON-en din forlater aldri nettleseren. Parseren, formateringen og diffen kjører alle på maskinen din, lokalt. Ingen analyse av input, ingen logger, ingen "hjelpsom" sky-rundtur. Parsing bruker nettleserens innebygde JSON.parse, og JSON-spesifikasjonen vi følger er RFC 8259.