SmartKitio

Technology

Why Software Uses Different Data Formats

Formats are contracts. Pick the wrong one and you pay in size, fragility, or human pain. Pick a good one and tools across languages can cooperate.

6 min read · Updated 2026-10-04

Analytics dashboard on a monitor
Photo via Unsplash · Unsplash License

Quick answer

Programs store and exchange data as bytes. Whether those bytes look like readable text or opaque binary is a design choice driven by who must read it (humans, scripts, or only machines), how much wire size matters, and how strictly the shape of data must be enforced. JSON fits web APIs and config; CSV fits rectangular exports; Protobuf fits high-throughput RPC; PNG fits lossless icons; SQLite fits embedded relational queries—none replaces the others outright.

Why format choice keeps coming up

Integration projects fail more often on ambiguous bytes than on missing features. A partner sends CSV with semicolon delimiters; your importer expects commas. An API returns JSON numbers as strings because IDs exceed safe integer range. A mobile client expects Protobuf but the gateway emits JSON for debugging and forgets to switch back in production.

Formats also encode social contracts: finance teams live in spreadsheets, mobile teams want compact RPC, legal teams want archivable XML with signatures, and data science pipelines want Parquet or SQLite extracts. Choosing one format for every layer forces expensive adapters at each boundary.

Text formats vs binary formats

Text formats encode information in characters from defined alphabets—mostly UTF-8 on the wire today. You can open them in an editor, email them, and diff them in version control. Binary formats pack numeric types, length prefixes, and compressed bitmaps without guaranteeing human legibility. Parsing binary is usually faster and smaller because there is no lexical scanning of braces and quotes.

Human-first vs machine-first

Text (JSON, CSV, XML)

  1. 1

    Readable in a terminal

  2. 2

    Easy to grep and code-review

  3. 3

    Larger on disk and network

  4. 4

    Ambiguity unless schema is documented

Binary (Protobuf, MessagePack, SQLite file)

  1. 1

    Compact and fast to parse

  2. 2

    Schema or spec required

  3. 3

    Opaque without tooling

  4. 4

    Strong typing on the wire

JSON

JSON maps objects, arrays, strings, numbers, booleans, and null into a minimal syntax. Web browsers expose JSON.parse and JSON.stringify, which helped JSON displace XML for many APIs. Strict JSON has no comments and duplicate keys are discouraged—validators catch mistakes early.

  • Strength: universal libraries; natural fit for REST and config files.
  • Weakness: numbers are IEEE doubles—integers beyond 2^53 need strings in JS.
  • Weakness: verbose compared with binary; nested objects repeat field names on the wire.
json
{
  "query": "blue shirt",
  "page": 1,
  "filters": { "inStock": true }
}

Nested objects like filters above flatten awkwardly into CSV without conventions (JSON column, repeated headers, or denormalized rows). That impedance mismatch is a feature signal: stay on JSON when rows are not flat.

json
{
  "id": 1042,
  "name": "Ana Rivera",
  "email": "ana@example.com",
  "active": true
}
text
id,name,email,active
1042,Ana Rivera,ana@example.com,true

CSV

Comma-separated values (sometimes semicolon in locales) represent tables as one row per line. Spreadsheets import CSV without ceremony. The format looks trivial until commas appear inside cells, locales use different decimal separators, or newline characters sit inside quoted fields.

XML

XML tags data with nested elements and attributes, plus namespaces for mixing vocabularies. Schema languages (XSD) can enforce structure more rigidly than typical JSON. Document markup (Office files, SVG, RSS) still rides on XML; many greenfield HTTP APIs chose JSON instead for brevity and JavaScript affinity.

XML shines when mixed content matters—paragraphs with inline bold—or when industries standardized on particular schemas decades ago. JSON Schema and OpenAPI partially fill the validation role XML stacks had, but tooling maturity still differs by ecosystem.

Binary interchange: Protobuf and MessagePack

Protocol Buffers compile a .proto schema into typed structs in many languages. On the wire, field tags and varints replace repeated key strings. MessagePack is schemaless binary JSON-like encoding—handy when you want smaller payloads without maintaining .proto files.

Both require agreement on field numbers or type tags. Evolving schemas demands rules: add optional fields, never reuse numbers, reserve deprecated tags. That discipline buys compatibility at scale inside data centers.

Images and media

PNG preserves pixels losslessly and supports transparency—good for UI assets. JPEG trades lossy compression for photos. WebP and AVIF aim for smaller files with modern codecs. These are not general data containers; forcing arbitrary files through image formats would be absurd, but teams still “pick PNG vs JPEG” when the payload is inherently visual.

SQLite and single-file databases

SQLite stores relational tables in one binary file with transactional semantics. Mobile apps and browsers (via WebAssembly or native bindings) use it for offline search and structured caches. Unlike JSON lines in a folder, SQLite gives indexed queries without standing up a server—at the cost of opaque files and backup tooling that understands WAL mode.

Exporting a report as JSON gives you one big document; exporting as .sqlite gives analysts JOINs and indexes. Conversely, emailing a SQLite file to someone who only has Excel invites friction—meet recipients where their tools already are.

Carrying bytes through text channels

Email attachments, JSON fields that must hold a certificate, and data URLs sometimes embed raw bytes as Base64 text. Encoding expands size by roughly four-thirds and requires decode on receipt. It is a transport hack, not a replacement for choosing the right underlying format.

Base64 expansion ≈ 4/3 × original byte length (plus padding)

Comparison at a glance

Format trade-offs (typical use, not exhaustive)

FormatBest whenWatch out for
JSONWeb APIs, config, logs to humansSchema drift; large nested payloads
CSVSpreadsheet exchange, simple tablesQuoting, locales, types as strings
XMLDocuments, legacy enterprise integrationVerbosity; complex schema tooling
ProtobufInternal RPC, versioned messagesNeeds code gen and schema discipline
MessagePackCompact JSON-like without .protoNo universal human readability
PNG / JPEG / WebPPhotos and UI bitmapsWrong tool for arbitrary binary
SQLite fileEmbedded relational data offlineBinary file; migration versioning
Base64 in textEmbed bytes in JSON/XML/emailSize overhead; not encryption

How to choose without dogma

  1. Identify the consumer: person in Excel, browser script, or microservice in Go.
  2. Decide whether a formal schema and backward compatibility matter across years.
  3. Measure payload size and parse time on realistic data—not hello-world examples.
  4. Check security: never execute CSV formulas blindly; sanitize XML external entities in legacy parsers.
  5. Prefer conversion at boundaries: store canonical JSON internally, export CSV for finance, ship Protobuf inside your cluster.

Interchange formats win on ubiquity long before they win on elegance.

— Practical integration wisdom

Try it yourself

Inspect and transform data locally before it crosses a trust boundary. Formatting and validating JSON catches trailing commas and type mistakes. Converting between JSON and CSV reveals whether your table is really rectangular or hiding nested structures. Base64-encoding a small file shows the size penalty of embedding binary in text.

  • JSON Formatter — readable structure for review and diffs.
  • JSON Validator — strict syntax check before deployment.
  • JSON to CSV / CSV to JSON — test whether your export model matches reality.
  • Base64 Encoder — see encoded size versus raw bytes.

Encoding is not encryption. Base64 and URL encoding transform representation; they do not protect secrets from anyone who sees the string.

JSON’s rise has as much to do with browser ergonomics as with syntax. Unicode and UTF-8 explain why text formats break when encodings mix. Separating encoding from encryption keeps security reviews honest when someone proposes “just Base64 it.”

References

  1. RFC 8259 — JSON data interchange format
  2. Protocol Buffers documentation
  3. SQLite — file format
  4. RFC 4648 — Base64 encoding

Related articles