Indsæt, formatér og sammenlign to JSON-uddrag side om side. Validering, pretty-print og minify indbygget.
Et gratis værktøj i browseren til at sammenligne to JSON-dokumenter. Indsæt en gammel version til venstre, den nye til højre, og forskellene lyser op tegn for tegn. Intet forlader din maskine.
Den bruger din browsers indbyggede JSON.parse til validering. Der er en Format-knap, når din JSON er én kæmpe minificeret linje, en Minify-knap til det modsatte tilfælde, og live validering, der markerer syntaksfejl, mens du skriver.
Hvis du nogensinde har stirret på en 6.000 linjers openapi.json-diff i en GitHub-PR og forsøgt at finde det ene felt, der ødelagde en downstream-klient, er dette værktøjet, der bringer dig derhen på sekunder.
Sammenligningen sker på tegnniveau og bliver derefter ryddet op med semantisk efterbehandling, så markeringerne lander på meningsfulde stykker frem for tilfældige tegn. Indsættelser vises i grønt i højre rude, sletninger i rødt i venstre.
JSON har sine egne særheder, som specifikationen påpeger. JSON-specifikationen i RFC 8259 definerer objekter som uordnede, så omarrangering af nøgler er teknisk set en ikke-handling, selvom en tekstdiff vil flagge det. Vi håndterer det ved at give dig en Format-knap på hver side: formatér begge, sammenlign så, og rækkefølgen er konsistent. Til dybere strukturelt arbejde, se JSON Patch (RFC 6902) eller det enklere JSON Merge Patch-format (RFC 7396), som er de to standardmåder at beskrive en JSON-ændring som data.
Når rækkefølgen har betydning for hashing eller signering, er RFC 8785 (JSON Canonicalization Scheme) den relevante specifikation. Sortér nøgler, normalisér talformatering, og lav så diff.
To tekstruder, én diff. Ingen tilmelding, ingen upload, ingen serverrundtur.
Indsæt den gamle JSON til venstre, den nye JSON til højre. Eller klik på Upload på en af siderne for at indlæse en .json-fil direkte. Sample-knappen fylder begge ruder med et lille eksempel, hvis du først vil se værktøjet i aktion.
Klik på Format i hver rude for at pretty-printe med to mellemrums indrykning. Dette normaliserer mellemrum og linjeskift, så diff'en fremhæver faktiske dataændringer, ikke formateringsforskelle. Valideringsmærket bliver grønt, når din JSON parses rent.
Sletninger vises med rød markering til venstre, indsættelser med grøn markering til højre. Rul i den ene side, og den anden følger efter. Ændringstællingerne i hver overskrift fortæller dig, hvor mange forskellige redigeringer diff'en fandt.
Indsæt det aktuelle output af aws iam get-policy-version over for den foreslåede JSON for at se nøjagtigt, hvilke Action-poster der er tilføjet, eller om nogen har sneget "Resource": "*" ind i et tidligere specifikt statement. AWS-konsollen omarrangerer statements ved gem, hvilket gør en GitHub-diff vildledende; formatér begge sider her, og den reelle ændring er tydelig.
Når terraform show -json tfplan returnerer en 4 MB blob, er det håbløst at kigge med øjnene. Sammenlign dagens plan med gårsdagens for at få den aws_security_group_rule frem, som nogen tilføjede under en refactor-PR, eller lifecycle.ignore_changes-blokken, der stille forsvandt.
En 6.000 linjers openapi.json-diff er ulæselig, når en kodegenerator omarrangerer paths alfabetisk. Formatér begge sider, sammenlign, og den faktiske ændring kommer frem: et required-felt tilføjet til CreateOrderRequest, eller en 200-respons, hvis skema stille skiftede fra string til string | null.
Efter at have løst en package-lock.json-konflikt skal du sammenligne din løste fil med main's lockfile for at fange en transitiv nedgradering. npm løser nogle gange det samme semver-interval til forskellige eksakte versioner på tværs af maskiner, hvilket er den egentlige årsag til "virker på min maskin, fejler i CI". Læs package-lock.json-dokumentationen for at se, hvad hvert felt betyder.
Træk GET /my-index/_mapping fra staging og prod, smid begge i diff'en. Prod har måske stadig "type": "text" på et felt, som staging migrerede til "keyword" sidste sprint, hvilket er grunden til, at aggregation-forespørgslen ikke returnerer noget i prod og virker lokalt. Mappings nestes fem eller seks niveauer dybt, og en tekstdiff begraver dette i støj.
Når en Playwright-test består lokalt og fejler i CI, så fang den JSON-responskrop, testen faktisk så, og sammenlign den med fixturen i dit repo. Ofte er det et createdAt-tidsstempel eller et traceId-felt, som ingen har pinned, og den strukturelle diff gør den syndige nøgle åbenlys i stedet for at dumpe dig i en mur af formateret tekst.
Et kort snydeark til de parse-grænsetilfælde, dette værktøj får frem oftest. Det hele er forankret i JSON-specifikationen.
| Topic | What this tool does |
|---|---|
| Objektnøglerækkefølge | Uordnet ifølge specifikationen. {"a":1,"b":2} er lig med {"b":2,"a":1}. Brug Sortér nøgler til at normalisere før sammenligning. |
| Array-rækkefølge | Ordnet. [1,2,3] er ikke lig med [3,2,1]. Sortér manuelt, hvis rækkefølgen ikke har betydning for dit use case. |
| Efterstillede kommaer | Ikke tilladt. { "a": 1, } er en parsefejl i standard-JSON. Tilladt i JSON5/JSONC, som er udvidelser — fjern dem først. |
| Kommentarer | Ikke tilladt. // som dette er en parsefejl. JSON5 og JSONC accepterer dem; dette værktøj følger den strenge RFC 8259-grammatik. |
| Tal | Parses som 64-bit IEEE 754 floats. 0.1 + 0.2 = 0.30000000000000004. Heltal over 2^53 − 1 mister præcision; gem snowflake ID'er som strenge. |
| Duplikerede nøgler | Specifikationen kalder det udefineret adfærd. De fleste parsere beholder den sidste forekomst. Diff'en viser dem alle, hvilket normalt er det, du ønsker, når du reviderer konfigurationsfiler. |
| Kodning | Kun UTF-8. RFC 8259 forbyder en UTF-8 BOM i starten af dokumentet; nogle parsere accepterer det alligevel, men specifikationen gør ikke. |
| Null vs. manglende | En nøgle med værdien null er til stede. En manglende nøgle er fraværende. Forskellig fra JavaScript's undefined, som ikke har nogen JSON-repræsentation. |
Nej. Diff'en kører helt i din browser. Intet sendes til en server, logges eller lagres. Indsæt et internt API-svar eller en IAM-policy og luk fanen; der er ingen kopi tilbage. For at verificere, åbn DevTools, skift til Network-fanen og kig med — der er ingen udgående anmodninger, når du sammenligner.
Ja, det gør de begge. En tekstdiff sammenligner tegn linje for linje, så omformatering, omarrangerede nøgler eller mellemrumsændringer dukker op som forskelle, selv når dataene er identiske. Klik på Format-knappen i begge ruder for at pretty-printe først, og diff'en fokuserer på reelle dataændringer. For en fuldt strukturel sammenligning, der ignorerer nøglerækkefølgen, skal du sortere nøglerne på begge sider, før du sammenligner.
For objektnøgler nej — JSON-specifikationen siger, at objekter er uordnede, så {"a":1,"b":2} og {"b":2,"a":1} repræsenterer de samme data. En tegndiff vil stadig flagge omarrangeringen, hvilket er grunden til, at Format-knappen er vigtig. Arrays er anderledes: [1,2,3] og [3,2,1] er ikke ens, fordi array-rækkefølgen er meningsfuld i JSON.
Fordi IEEE 754 flydende komma. 0.1 + 0.2 er faktisk 0.30000000000000004, og JSON.parse læser tal som 64-bit floats. Store heltal rammer den samme grænse: alt over 2^53 - 1 (9007199254740991) mister præcision, så et Twitter-style snowflake ID overlever ikke en rundtur. Hvis præcision er vigtig, så gem dem som strenge.
Standard-JSON tillader ingen af delene. { "a": 1, } eller // kommentar giver dig en parsefejl. Det er JSON5 eller JSONC (formatet, VS Code bruger til settings.json), som er en udvidelse. Fjern kommentarerne og de efterstillede kommaer først. Vi følger bevidst den strenge RFC 8259-grammatik, så diff'en matcher det, dit API faktisk accepterer.
Op til et par MB er fint, under et sekund. Forbi 10 MB begynder browseren at mærke det, mest fordi det er at rendere diff'en (ikke at beregne den), der bliver dyrt. For 50 MB+ eksporter skal du filtrere begge sider til det undertræ, du interesserer dig for, med jq først, og så indsætte det.
Din JSON forlader aldrig din browser. Parseren, formateringen og diff'en kører alle på din maskine, lokalt. Ingen analytics på dit input, ingen logs, ingen "hjælpsom" cloud-rundtur. Parsing bruger browserens indbyggede JSON.parse, og den JSON-specifikation, vi følger, er RFC 8259.