Hur Douglas Crockford populariserade JSON och varför det blev standard för webbappar och API:er — plus praktiska tips för att använda JSON väl idag.

JSON (JavaScript Object Notation) är ett lättviktigt sätt att representera data som ren text med nyckel–värde‑par och listor.
Om du bygger webbappar — även om du inte tänker så mycket på ”dataformat” — är JSON förmodligen redan det lim som håller produkten samman. Det är hur ett frontend ber om data, hur en backend svarar, hur mobilappar synkroniserar tillstånd och hur tredjepartstjänster skickar händelser. När JSON är tydligt och konsekvent levererar team snabbare; när det är rörigt tar varje funktion längre tid eftersom alla bråkar om vad datan ”betyder”.
Här är ett litet JSON‑objekt som du kan läsa på en gång:
{
"userId": 42,
"name": "Sam",
"isPro": true,
"tags": ["beta", "newsletter"]
}
Även utan teknisk kontext kan du oftast lista ut vad som händer: en användare har ett ID, ett namn, en statusflagga och en lista med taggar.
Du kommer att lära dig:
Målet är enkelt: hjälpa dig att förstå inte bara vad JSON är, utan varför nästan varje app ”talar” det — och hur du undviker vanliga misstag som team fortsätter att göra.
Douglas Crockford uppfann inte alla idéer bakom JSON, men han gjorde något lika viktigt: han synliggjorde ett enkelt, fungerande mönster, gav det ett namn och plöjde vägen för att få det att slå igenom.
I webapputvecklingens tidiga dagar jonglerade team med klumpiga alternativ för att flytta data mellan webbläsare och server. XML var vanligt men ordrikt. Anpassade format med avgränsare var kompakta men sköra. JavaScript kunde tekniskt sett utvärdera data som kod, men det suddade ut gränsen mellan ”data” och ”körbar kod”, vilket var en grogrund för buggar och säkerhetsproblem.
Crockford såg en renare väg: använd en liten delmängd av JavaScript‑literal syntax som på ett tillförlitligt sätt kan representera vanlig data — objekt, arrayer, strängar, siffror, booleaner och null — utan extra funktioner.
Ett av Crockfords största bidrag var socialt snarare än tekniskt: han kallade det JSON (JavaScript Object Notation) och publicerade tydlig dokumentation på json.org. Det gav team ett gemensamt vokabulär (”vi skickar JSON”) och en referens som var tillräckligt kort för att läsa och tillräckligt strikt för att implementera.
Han drev också JSON som ett dataformat oberoende av JavaScript som programmeringsspråk: många språk kunde parsa och generera det, och det mappade naturligt till vanliga datastrukturer.
Antagande accelererar när team känner sig trygga att satsa på ett format långsiktigt. JSON fick gradvis den statusen genom välkända milstolpar:
Crockfords pådrivande, kombinerat med dessa standarder och ett växande ekosystem av parsers, hjälpte JSON att gå från en praktisk konvention till standarden för hur appar pratar — särskilt över HTTP‑API:er (behandlas senare i bloggen i avsnittet json‑and‑apis).
Innan JSON blev standard för att flytta data använde webben en blandning av format som antingen var för tunga, för inkonsekventa eller för anpassade för att skala mellan team.
XML var det stora ”standard”‑valet. Det fungerade över språk, hade verktyg och kunde representera nästlade strukturer. Det medförde dock mycket ceremoni.
Samtidigt skickade många appar data som anpassade query strings (särskilt i tidiga AJAX‑förfrågningar): nyckel/värde‑par i URL:er eller POST‑kroppar. Andra hittade på ad‑hoc textformat — en kommaseparerad lista här, en pipe‑separerad blob där — ofta med handgjorda escaping‑regler som bara en utvecklare förstod.
De vanliga problemen var inte teoretiska:
De flesta appar behöver inte ett format som kan uttrycka varje möjlig dokumentstruktur. De behöver ett förutsägbart sätt att skicka objekt, arrayer, strängar, siffror och booleaner — snabbt, konsekvent och med minimal tolkning. Enklare format minskar antalet beslut (och misstag) team gör per endpoint.
<user>
<id>42</id>
<name>Ada</name>
<isActive>true</isActive>
</user>
{
"id": 42,
"name": "Ada",
"isActive": true
}
Båda uttrycker samma idé, men JSON är lättare att skumma, lättare att generera och närmare hur de flesta applikationer modellerar data i minnet.
JSONs uthållighet är ingen slump. Det lyckas för att det är avsiktligt litet: precis tillräcklig struktur för att representera verkliga applikationsdata utan att bjuda in ändlösa variationer.
JSON ger dig ett minimalt verktyg som mappas rent till hur de flesta appar tänker kring data:
name, email)true/falseDet är allt. Inga datum, inga kommentarer, inga anpassade numeriska typer, inga referenser. Denna enkelhet gör JSON lätt att implementera i olika språk och plattformar.
JSON är tillräckligt läsbart för att människor ska kunna skumma loggar och API‑svar, samtidigt som det är lätt för maskiner att parsa snabbt. Det undviker onödig ceremoni men behåller tydliga avgränsare ({}, [], :) så parsers kan vara snabba och pålitliga.
Tradeoffen: eftersom JSON är så minimal måste team komma överens om konventioner för saker som tidsstämplar, pengar och identifierare (till exempel ISO‑8601‑strängar för datum).
JSONs strikta regler (dubbelciterade strängar, inga avslutande kommatecken, en liten fast uppsättning typer) minskar tvetydighet. Mindre tvetydighet betyder färre ”det funkar på min maskin”‑fel när olika system utbyter data.
JSON ser ut som JavaScript‑objekt‑syntax, men JSON är inte JavaScript. Det är ett språkneutralt dataformat med egna regler, användbart från Python, Java, Go, Ruby och varhelst man behöver konsekvent serialisering och interoperabilitet.
JSON vann inte för att det var mest funktionsrikt. Det vann för att det passade hur webbappar redan byggdes: en JavaScript‑tung klient som pratade med en server över enkla HTTP‑förfrågningar.
När webbläsare standardiserade kring JavaScript hade klienten ett inbyggt sätt att representera strukturerad data: objekt, arrayer, strängar, siffror, booleaner och null. JSON speglade dessa primitiva typer nära, så att flytta data mellan ”vad webbläsaren förstår” och ”vad servern skickar” kändes naturligt.
Tidiga Ajax‑appar påskyndade detta. Istället för att returnera fulla HTML‑sidor kunde servrar returnera en liten payload som UI:t renderade. Ett svar som detta var omedelbart användbart:
{
"user": {"id": 42, "name": "Sam"},
"unreadCount": 3
}
Trots att JSON‑syntaxen liknar JavaScript är den språkneutral. Så fort servrar och klienter i andra språk behövde interagera med webbfrontends dök JSON‑bibliotek upp — och blev snabbt ”standardutrustning.” Att parsa en JSON‑sträng till nativen datastrukturer är vanligtvis ett funktionsanrop, och att generera JSON är lika enkelt.
När ramverk, API‑klienter, debuggers, proxies och dokumentationsverktyg antog JSON skapade ett annat val friktion. Utvecklare kunde inspektera payloads i webbläsarens devtools, klippa/klistra exempel i tester och lita på mogna bibliotek för kodning, avkodning och felhantering.
Ett enda JSON‑svar kan tjäna ett webb‑UI, en mobilapp, en intern tjänst och en tredjepartsintegration med små förändringar. Den interoperabiliteten gjorde JSON till ett säkert val för team som byggde ”en backend, många frontends” — och bidrog till att det blev kontraktet mellan klient och server.
JSON vann inte för att det var fancy — det passade snyggt ihop med hur webben redan fungerade. HTTP är byggt runt att skicka en förfrågan och få ett svar, och JSON är ett enkelt, förutsägbart sätt att representera kroppens data (request eller response) som strukturerad data.
En API‑förfrågan innehåller vanligtvis en metod och en URL (till exempel GET /users?limit=20). Servern svarar med en statuskod (som 200 eller 404), headers och en valfri kropp.
När kroppen är JSON är en viktig header:
Content-Type: application/jsonDen headern talar om för klienter hur de ska tolka bytena de får. På vägen in (klient → server), signalerar Content-Type: application/json ”jag postar JSON”, och servrar kan parsa det konsekvent.
JSON fungerar särskilt bra för upprepade mönster som dyker upp i många API:er.
Pagination omsluter ofta en lista med metadata:
{
"data": [{"id": 1, "name": "A"}],
"pagination": {"limit": 20, "offset": 0, "total": 153}
}
Filtrering och sortering sker ofta i URL:ens query string, medan resultaten förblir en JSON‑array (eller ett data‑fält). Till exempel: GET /orders?status=paid&sort=-created_at.
Felrespons tjänar på en standardiserad form så klienter kan visa meddelanden och hantera retries:
{
"error": {
"code": "invalid_request",
"message": "limit must be between 1 and 100",
"details": {"field": "limit"}
}
}
Den praktiska matchningen är enkel: HTTP ger leverans och mening (verb, statuskoder, caching), medan JSON ger en lättviktig, människoläsbar struktur för själva datan.
När folk jämför JSON och XML jämför de ofta egentligen ”data för appar” mot ”data för dokument”. Båda formaten kan representera strukturerad information, men JSON tenderar att matcha vad de flesta applikationer faktiskt flyttar: enkla objekt, listor, strängar, siffror, booleaner och null.
XML är ordrikt av design. Upprepade öppnings‑ och stängningstaggar gör payloads större och svårare att skumma i loggar eller nätverksinspektörer. JSON förmedlar ofta samma mening med färre tecken och mindre visuellt brus, vilket hjälper vid debug och kan minska bandbreddskostnader i stor skala.
Detta handlar inte bara om estetik: mindre payloads innebär ofta snabbare överföringar och mindre arbete för parsers och proxies.
Det mesta appdata ser naturligt ut som dictionaries (key/value maps) och arrayer (listor): en användare med attribut, en order med radposter, en sida med komponenter. JSON mappar direkt till den här mentala modellen och stämmer överens med nativen datastrukturer i JavaScript och de flesta moderna språk.
XML kan representera samma strukturer, men kräver ofta konventioner: attribut vs element, upprepade barn‑element för listor och extra regler för ”vad som räknas som ett tal” (eftersom allt är text om du inte lägger till typning ovanpå).
XML är fortfarande starkt för dokumentcentrerade användningsfall: blandat innehåll (text med insprängd markup), publicerings‑arbetsflöden och ekosystem med mogna XML‑verktyg (t.ex. vissa företagsintegrationer). Om din payload är mer ett dokument än en objektgraf kan XML vara ett bra val.
Om ditt primära mål är att utbyta applikationsdata mellan frontend, backend och API:er är JSON oftast det enklare och mer direkta valet. Om du behöver dokumentmarkup, blandat innehåll eller ska integrera i ett XML‑tungt domän kan XML vara bättre.
JSON ser ut som ”JavaScript‑objekt”, så team antar ofta att de kan behandla det som JavaScript. Där smyger buggar in: JSON är striktare, mindre och mindre förlåtande.
Ett par ”det funkar på min maskin”‑problem dyker upp om och om igen:
{name: "Ada"} är inte JSON; { "name": "Ada" } är det.{ "a": 1, } kommer att misslyckas i många parsers.// och /* ... */ är ogiltiga. Om du behöver anteckningar, håll dem i dokumentation eller använd ett separat fält (med försiktighet) under utveckling.Dessa begränsningar är avsiktliga: de håller parsers enkla och konsekventa över språk.
JSON har bara en numerisk typ: number. Det finns ingen inbyggd integer, decimal eller datum.
"19.99") för att undvika avrundningsskillnader mellan system."2025-12-26T10:15:30Z"). Undvik egna datumformat som kräver gissningar.JSON är Unicode, men verkliga system snubblar fortfarande över encoding och escaping:
" och backslash \\).Parsa alltid JSON med en riktig JSON‑parser (JSON.parse eller motsvarande i ditt språk). Undvik eval‑liknande tillvägagångssätt, även om det ”verkar snabbare”. Validera input i gränsytan — särskilt för publika API:er — så oväntade fält eller typer inte kryper in i affärslogik.
En JSON‑payload är inte bara ”data på väg” — det är ett långsiktigt gränssnitt mellan team, system och framtida du. Skillnaden mellan en payload som håller och en som måste skrivas om varje kvartal är oftast tråkig disciplin: konsekvens, noggrann ändringshantering och prediktiva kantfall.
Välj namngivningsregler och håll fast vid dem överallt:
camelCase eller snake_case) och blanda inte.userId till id är ett brytande ändringsfall även om betydelsen verkar uppenbar."count": 3 vs "count": "3") kommer orsaka buggar som är svåra att spåra.Du kan undvika de flesta versionsstrider genom att göra ändringar additiva:
/v2/...) eller inkludera en tydlig versionssignal i en header — ändra inte semantics i tystnad.Klienter hanterar fel bäst när fel delar samma form:
{
"error": {
"code": "INVALID_ARGUMENT",
"message": "email must be a valid address",
"details": { "field": "email" }
}
}
Bra JSON‑dokumentation innehåller verkliga exempel — både lyckade och felande svar — med kompletta fält. Håll exempel synkade med produktionsbeteende och markera vilka fält som är valfria, nullable eller deprecierade. När exempel stämmer överens med verkliga svar går integrationer snabbare och brister mindre.
Om du använder en vibe‑coding‑arbetsflöde för att snabbt snurra upp nya funktioner blir JSON‑kontrakt ännu viktigare: snabb iteration är bra tills klienter och tjänster glider isär.
På Koder.ai genererar team ofta ett React‑frontend plus en Go + PostgreSQL‑backend och itererar sedan API‑former i planning mode innan de låser dem. Funktioner som snapshots och rollback hjälper när en ”liten” JSON‑ändring visar sig vara brytande, och export av källkod gör det enkelt att hålla kontraktet i ditt repo och testa det.
JSON är lätt att generera, vilket är både dess styrka och dess fälla. Om en tjänst skickar "age": "27" (sträng) och en annan förväntar sig 27 (nummer) stoppar ingenting i JSON det. Resultatet är ofta den värsta typen av bugg: en klientkrasch i produktion eller en subtil UI‑glitch som bara händer med vissa data.
Validering handlar om att fånga felaktig eller oväntad data innan den når de som litar på den — ditt frontend, partnerintegrationer, analys‑pipeline eller mobilappar.
Vanliga felpunkter inkluderar saknade obligatoriska fält, omdöpta nycklar, fel typer och ”nästan rätt”‑värden (som datum i inkonsekventa format). Ett litet valideringssteg i API:ets gränsyta kan göra dessa till tydliga felmeddelanden istället för driftstörningar.
JSON Schema är ett standardiserat sätt att beskriva hur din JSON bör se ut: obligatoriska egenskaper, tillåtna typer, enums, mönster och mer. Det är mest användbart när:
Med ett schema kan du validera förfrågningar på servern, validera svar i tester och generera dokumentation. Många team parar det med sina API‑docs (ofta via OpenAPI), så kontraktet blir explicit istället för ”tribalt kunnande”. Om du redan publicerar utvecklardokumentation kan du länka schemaupp exempel i dokumentationen utan att lägga in faktiska länkar här.
Inte varje team behöver full schemaverktyg från dag ett. Praktiska alternativ inkluderar:
En användbar regel: börja med exempel och kontraktstester, lägg till JSON Schema när förändringar och integrationer börjar multiplicera.
JSON känns ”lätt” när du skickar ett par fält. I skala — mobilklienter på ostabila nätverk, högtrafikerade API:er, analys‑tunga sidor — kan JSON bli ett prestandaproblem eller en risk för tillförlitlighet om du inte formar och skickar det omsorgsfullt.
Det vanligaste skalningsproblemet är inte JSON‑parsning — det är att skicka för mycket av den.
Pagination är den enkla vinsten: returnera förutsägbara chunkar (t.ex. limit + cursor) så klienter inte laddar tusentals poster samtidigt. För endpoints som returnerar nästlade objekt, överväg partiella svar: låt klienten be om bara det den behöver (valda fält eller ”include”‑expansioner). Det förhindrar ”overfetching”, där en skärm bara behöver name och status men får all historik och konfigurationsfält.
En praktisk regel: designa svar kring användarens handlingar (vad en vy behöver nu), inte kring vad din databas kan join:a.
Om ditt API serverar stora JSON‑svar kan komprimering dramatiskt minska överföringsstorleken. Många servrar kan gzip eller brotli‑komprimera svar automatiskt, och de flesta klienter hanterar det utan extra kod.
Caching är det andra spåret. På hög nivå sträva efter:
Detta minskar upprepade nedladdningar och jämnar ut trafiktoppar.
För mycket stora outputs — exporter, event‑flöden, bulk‑synkronisering — överväg streaming eller inkrementell parsning så klienter inte behöver ladda hela dokumentet i minnet innan de gör något användbart. Det krävs inte för de flesta appar, men är ett värdefullt alternativ när ”en stor JSON‑blob” börjar timeout:a.
JSON är enkelt att logga, vilket är både hjälpsamt och farligt. Behandla loggar som en produktyta:
Görs det väl debuggar du snabbare samtidigt som risken för oavsiktlig dataexponering minskar.
JSON är inte ”färdigt” — det är stabilt. Det som förändras nu är ekosystemet runt det: bättre editorer, starkare validering, säkrare API‑kontrakt och mer verktyg som hjälper team att undvika oavsiktliga brytande ändringar.
JSON kommer sannolikt att förbli standardformatet för de flesta webb‑ och mobilappar eftersom det stöds brett, är lätt att debugga och mappar rent till vanliga datastrukturer.
Den största förändringen handlar om typade API:er: team skickar fortfarande JSON, men definierar det mer precist med verktyg som JSON Schema, OpenAPI och kodgeneratorer. Det innebär färre ”gissa formen”‑stunder, bättre autocomplete och tidigare felupptäckt — utan att överge JSON.
När du behöver skicka eller lagra många poster effektivt (loggar, analytiska events, exporter) kan en enda gigantisk JSON‑array vara opraktisk. JSON Lines (även kallat NDJSON) löser detta genom att lägga ett JSON‑objekt per rad. Det strömmar bra, kan bearbetas rad‑för‑rad och fungerar väl med kommandoradsverktyg.
Använd detta som en snabb preflight‑check för payloads som ska leva längre än en sprint:
2025-12-26T10:15:00Z).null och dokumentera ditt val.Om du vill gå djupare, läs relaterade guider i bloggen — speciellt ämnen som schema‑validering, API‑versionering och design av payloads för långsiktig kompatibilitet.