Solana Stores Bytes, Not JSON. Here's What That Actually Means

I spent weeks reading Solana accounts through explorers and RPC calls, seeing nicely formatted data token balances, authorities, supply numbers and thinking that's what Solana stored.

It isn't. Solana stores raw bytes.

Day 24 of #100DaysOfSolana made this uncomfortably real.

The Moment It Clicked

The challenge was to fetch the Wrapped SOL mint account from mainnet and decode it three different ways: using an SPL Token decoder, manually byte by byte, and via the RPC's jsonParsed output.

When I fetched the raw account data it looked like this:

82 bytes of nothing, apparently. No field names. No labels. Just numbers.

But here's the thing those 82 bytes contain everything: the total supply of Wrapped SOL, the number of decimals, the mint authority, the freeze authority, and whether the mint has been initialized. All of it, packed tightly into a flat array.

How Programs Know What the Bytes Mean

This is the key insight: the program that owns an account defines what its bytes mean.

The Token Program knows that bytes 0–3 are a discriminator, bytes 4–35 are the mint authority option, bytes 36–43 are the supply, byte 44 is the decimal count, and so on. It's essentially a binary schema baked into the program's code.

When you decode the account three ways with the SPL codec, manually, and via jsonParsedall three produce the same output:

json
{
  "mintAuthority": null,
  "supply": "0",
  "decimals": 9,
  "isInitialized": true,
  "freezeAuthority": null
}
Three approaches. One truth. The bytes were the truth all along.
Why This Changes How You Think About On-Chain Data
Solana explorers are doing you a favour you don't see. Every time you open explorer.solana.com and see a nicely formatted token account, the explorer is decoding those raw bytes using the program's known schema and presenting the result as readable JSON.
If you're building your own indexer, your own program, or your own tooling you don't get that favour for free. You need to know the schema. You need to decode the bytes yourself.
This is why Solana programs publish IDLs (Interface Definition Languages) so that clients know how to decode the data their program writes. Without an IDL, you're reading tea leaves.
The Bigger Picture
In Web2, your database stores typed fields. VARCHAR, BIGINT, BOOLEAN the database engine enforces types, and your ORM maps them to objects automatically.
On Solana, the "database" is just bytes. The "ORM" is the program's codec. The "schema" is whatever the program's developers decided and (hopefully) documented.
That's a lot more power and a lot more responsibility.
Raw bytes go in. Structured data comes out. Understanding what's in between is what separates someone who uses Solana from someone who understands it.