CSV och JSON är förmodligen de två vanligaste dataformaten du kommer att stöta på som utvecklare. CSV-filer dyker upp i kalkylbladsexporter, databasdumpar och datavetensskapspipelines. JSON finns överallt på webben — REST-API:er, konfigurationsfiler, NoSQL-databaser. Båda är ren text, båda är mänskligt läsbara och båda får jobbet gjort. Men de är byggda för olika dataformer, och att välja fel skapar riktiga problem. Den här artikeln går igenom kärnsskillnaderna, visar konkreta exempel på var varje format lyser (och bryter ihop) och ger dig en praktisk beslutsguide för att välja mellan dem.

Kärnsskillnaden: tabeller vs träd

CSV — definierat i RFC 4180 — är ett platt, tabellformat. Varje rad har samma kolumner, varje värde är en sträng. Det är allt. Det mappar perfekt på ett kalkylblad eller en databastabell: rader nedåt, kolumner tvärs.

JSON — specificerat i RFC 8259 och beskrivet på json.org — är ett hierarkiskt format. Värden kan vara objekt, arrayer, strängar, tal, booleaner eller null. Objekt nästas inuti objekt, arrayer håller olika former. Det mappar på hur data faktiskt lever i kod — poster med relationer, listor med olika saker, typade värden.

Ettradssummering: CSV är en tabell. JSON är ett träd. Om din data är en tabell är CSV enklare och mindre. Om din data har nesting kommer CSV antingen att förlora information eller tvinga dig till smärtsamma lösningar.

Samma data i båda format

Här blir skillnaden konkret. Föreställ dig en produktkatalog för en e-handelsbutik. Produkter har ett namn, ett pris och om de är i lager — enkelt. Men de har också varianter (storlekar, färger) och attribut (material, vikt). Låt oss se hur den datan ser ut i båda format.

I JSON är detta naturligt:

json
[
  {
    "id": "SHOE-001",
    "name": "Trail Runner Pro",
    "price": 129.99,
    "inStock": true,
    "attributes": {
      "material": "mesh",
      "weightGrams": 280
    },
    "variants": [
      { "size": 9,  "color": "black", "sku": "TR-9-BLK",  "qty": 12 },
      { "size": 9,  "color": "white", "sku": "TR-9-WHT",  "qty": 4  },
      { "size": 10, "color": "black", "sku": "TR-10-BLK", "qty": 7  }
    ]
  },
  {
    "id": "SHOE-002",
    "name": "City Walker",
    "price": 89.99,
    "inStock": true,
    "attributes": {
      "material": "leather",
      "weightGrams": 340
    },
    "variants": [
      { "size": 8,  "color": "brown", "sku": "CW-8-BRN",  "qty": 6  },
      { "size": 9,  "color": "brown", "sku": "CW-9-BRN",  "qty": 15 }
    ]
  }
]

Nu försök att lägga det i en CSV. Du har två alternativ, båda besvärliga. Alternativ ett: platta ut allt och upprepa överordnad data för varje variantrad:

csv
product_id,product_name,price,inStock,material,weightGrams,variant_size,variant_color,sku,qty
SHOE-001,Trail Runner Pro,129.99,true,mesh,280,9,black,TR-9-BLK,12
SHOE-001,Trail Runner Pro,129.99,true,mesh,280,9,white,TR-9-WHT,4
SHOE-001,Trail Runner Pro,129.99,true,mesh,280,10,black,TR-10-BLK,7
SHOE-002,City Walker,89.99,true,leather,340,8,brown,CW-8-BRN,6
SHOE-002,City Walker,89.99,true,leather,340,9,brown,CW-9-BRN,15

Produktnamnet, priset och attributen upprepas för varje variant. Det är dataöverflöd — inte stor sak för fem rader, men för en katalog med 50 000 produkter med 8 varianter vardera summerar det upp. Alternativ två: serialisera varianterna som en JSON-sträng inuti en CSV-kolumn — men nu bäddar du in JSON inuti CSV för att kringgå CSVs begränsningar, vilket är en code smell om det någonsin funnits en.

Där CSV vinner

Trots den begränsningen är CSV genuint det bättre valet i flera vanliga scenarier.

  • Kalkylblad och BI-verktyg. Excel, Google Sheets, Tableau, Looker, Power BI — de öppnar alla CSV nativt med ett klick. Ingen importguide, inget schema att definiera, inget transformationssteg. Om dina intressenter lever i kalkylblad är CSV vägen med minst motstånd.
  • Rent platt data. Om din data genuint är en tabell — analyshändelser, transaktionsloggar, sensoravläsningar, användarexport — är CSV mindre och enklare. Inga upprepade nycklar, inga parenteser, inget brus.
  • Databasimport/-export. Varje SQL-databas har ett COPY FROM CSV-kommando eller liknande. Det är standardutbytesformatet för massdataladdning och är storleksordningar snabbare än INSERT-satser.
  • pandas och datavetenskap. pandas.read_csv() är en av de mest använda funktionerna i Python-dataarbete. Hela ekosystemet — NumPy, scikit-learn, Polars — behandlar CSV som ett förstklassigt inmatningsformat.
  • Filstorlek för stora platta tabeller. Utan nyckelnamn på varje rad är CSV mindre för breda tabeller med många rader. En miljon-rad CSV med analyshändelser slår bekvämt den ekvivalenta JSON-arrayen.

Där JSON vinner

  • Kapslad och hierarkisk data. Så fort din data har någon struktur bortom en platt tabell — kapslade objekt, arrayer med olika former, relaterade poster — hanterar JSON det naturligt. CSV kan inte representera detta utan att förlora information eller skapa övertlöd.
  • Typbevarande. I CSV är allt en sträng. true, 42, null och "true" ser likadana ut. Du måste sluta dig till typer på mottagarsidan, vilket leder till buggar. JSON har nativa booleaner, tal och null. inStock: true är otvetydigt en boolean — inget gissande behövs.
  • REST-API:er och webben. JSON är webbens nativa dataformat. Varje HTTP-klientbibliotek, varje webbläsares Fetch API, varje REST och GraphQL API pratar JSON. Att skicka CSV via HTTP är möjligt men ovanligt — du skulle behöva anpassad parsning i båda ändar.
  • NoSQL-databaser. MongoDB, DynamoDB, Firestore, Elasticsearch, CouchDB — alla använder JSON (eller en binär supermängd som BSON) som sitt nativa dokumentformat. Du skriver in JSON, du får JSON tillbaka.
  • Konfigurationsfiler. package.json, tsconfig.json, manifest.json — verktygskonfiguration har standardiserats på JSON eftersom det stöder kapslade strukturer och är enkelt att programmatiskt generera och validera.
  • Schemavalidering. JSON Schema låter dig definiera den exakta formen på ett dokument och validera data mot det — typkontroller, obligatoriska fält, mönstermatchning, arraybegränsningar. CSV har ingen likvärdig standard.

Filstorlek: den verkliga historien

Påståendet "CSV är mindre" stämmer i ett specifikt fall: stora platta tabeller med många rader. Ta 100 000 analyshändelser, var och en med åtta fasta fält. I CSV visas fältnamnen en gång i rubriken. I JSON visas de på varje objekt. Den repetitionen summerar upp — JSON-arrayen kan vara 30–50% större än den ekvivalenta CSV:n.

Men vänd på scenariot till kapslad data och matematiken förändras. Den utplanade CSV:n av vår skokatalog upprepar produktnamnet, priset och attributen på varje variantrad. JSON-versionen lagrar varje produkt en gång. För djupt kapslad data med många upprepade föräldrafält kan JSON faktiskt vara mindre.

I praktiken, om filstorlek är ett verkligt problem, komprimeras båda formaten extremt väl med gzip — de upprepade nyckelnamnen i JSON och upprepade radvärden i CSV komprimeras båda kraftigt. Att servera gzippad JSON via HTTP är standardpraxis, och storleksskillnaden blir vanligtvis försumbar efter komprimering.

Jämförelse av verktyg

Verktygsstoryn för varje format återspeglar var det används mest.

CSV-verktyg: Excel, Google Sheets och LibreOffice Calc öppnar det nativt. Biblioteket pandas gör CSV till standardvalet för dataanalys i Python. Varje relationsdatabas har ett CSV-import/-exportkommando. Kommandoradsverktyg som csvkit och xsv låter dig filtrera, sammanfoga och aggregera CSV-filer utan att skriva kod. MIME-typen är text/csv, registrerad hos IANA.

JSON-verktyg: varje programmeringsspråk har en inbyggd eller standardbiblioteks-JSON-parser. JSON.parse() i JavaScript, json.loads() i Python, encoding/json i Go, serde_json i Rust. MDN JSON-referensen är en av de mest besökta sidorna på MDN. Kommandorad: jq är oumbärlig för att fråga och transformera JSON. IDE:er formaterar och validerar det automatiskt.

Om du arbetar med datapipelines som spänner över båda världarna — laddar JSON API-svar till ett datalager, eller exporterar databasposter till ett kalkylblad — konverterar du regelbundet mellan de två. Konverteraren CSV till JSON och JSON till CSV hanterar det snabbt. För att städa upp råa filer innan bearbetning är CSV Formatter och JSON Formatter värda att bokmärka.

Hybriden: JSON Lines (NDJSON)

Det finns ett tredje alternativ värt att känna till: JSON Lines, också kallat NDJSON (Newline-Delimited JSON). Idén är enkel — ett komplett JSON-objekt per rad, utan omgivande array.

json
{"id":"SHOE-001","name":"Trail Runner Pro","price":129.99,"inStock":true,"variantCount":3}
{"id":"SHOE-002","name":"City Walker","price":89.99,"inStock":true,"variantCount":2}
{"id":"SHOE-003","name":"Summit Hiker","price":159.99,"inStock":false,"variantCount":5}

Det här formatet ger dig det bästa av båda världarna för vissa användningsfall. Som CSV kan du strömma och bearbeta det rad för rad utan att ladda hela filen i minnet — kritiskt för stora loggfiler eller datapipelinerresultat. Som JSON kan varje rad ha ett annat schema och bevarar typer. Du kan använda standard Unix-verktyg (grep, wc -l, head) för att arbeta med det, men också pipea varje rad genom jq för strukturerade frågor.

NDJSON används flitigt för loggaggregering (det är standardutdataformatet för många strukturerade loggers), datapipelinesteg och ML-träningsdataexporter. Om du skriver ett skript som bearbetar miljontals poster och varje post är ett JSON-objekt, är NDJSON vanligtvis rätt val framför en gigantisk JSON-array — du undviker att ladda hela saken i minnet och kan enkelt återuppta från en kontrollpunkt.

python
import json

# Process a large NDJSON file without loading it all into memory
with open('products.ndjson', 'r') as f:
    for line in f:
        product = json.loads(line.strip())
        if product['inStock'] and product['price'] < 100:
            print(f"{product['name']} — ${product['price']}")

Beslutsguide: CSV vs JSON

Här är den praktiska versionen. När du väljer mellan de två, ställ dig dessa frågor:

  • Är din data genuint platt (ingen nesting, inga arrayer)? Om ja, är CSV enklare. Om nej, JSON.
  • Kommer en icke-utvecklare att konsumera den här filen? Analytiker i Excel? Affärsanvändare i Google Sheets? Använd CSV.
  • Serverar eller konsumerar du ett HTTP-API? Använd JSON. Fullt stopp.
  • Gör du en massimport eller massexport av databas? Använd CSV — varje databas stöder det nativt.
  • Har data blandade typer (booleaner, tal, null)? Använd JSON för att undvika typinferensfel på mottagarsidan.
  • Kommer filen att bearbetas rad för rad i en streamingpipeline? Överväg NDJSON som ett mellanting.
  • Lagrar du konfiguration? Använd JSON (eller YAML om kommentarer spelar roll för dig).
  • Behöver schemat variera per post? JSON. CSV upprätthåller samma kolumner på varje rad.
Det ärliga standardvalet: Om du bygger något för andra utvecklare eller maskiner att konsumera, använd JSON. Om du lämnar data till en människa som öppnar det i ett kalkylblad, använd CSV. Om du bygger en datapipeline som bearbetar miljontals strukturerade poster, överväg NDJSON.

Sammanfattning

CSV och JSON konkurrerar inte riktigt — de löser olika problem. CSV är rätt verktyg när din data är en tabell och du vill ha maximal kompatibilitet med kalkylblads- och databasverktyg. JSON är rätt verktyg när din data har struktur, typer eller nesting, och när du pratar med API:er eller applikationer.

Beslutet är vanligtvis inte svårt när du tittar på den faktiska formen på data. Platta rader av sensoravläsningar? CSV. Ett API-svar med kapslade användarprofiler och inbäddade orderhistorik? JSON. En strömningslogg av strukturerade händelser? NDJSON. Matcha formatet till formen på data och verktygen i varje ände, och du går sällan fel.

← All CSV articles Browse all categories →