A session cookie

Session and account

A session cookie is one line: a name, an equals sign, an opaque value, and then a series of attributes describing how the value is stored and sent.

The shape

You will not usually meet a cookie as text. It is set and read by software and never displayed. It appears in front of a person when something goes wrong, when a page prints a diagnostic, or when a support thread quotes one. The line has a strict grammar, and the grammar is the only part of it worth reading.

Field order

the name comes first, always, followed immediately by an equals sign with no space around it

Delimiter

a semicolon then a single space between the value and each attribute that follows

Value

one unbroken run from one alphabet. No spaces, no semicolons, no commas. Length is fixed by whoever issued it

Attribute names

drawn from a closed list, not invented per site

Attribute case

conventionally written with a leading capital, but compared without regard to case

Ends with

the last attribute. No trailing semicolon, no terminator, no closing marker

name=exampleexampleexampleexamplexxxx; Path=/; HttpOnly

the same line, shown as a skeleton: one name, an equals,
thirty two characters of one alphabet, then attributes
xxxx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx; Xxxx=x; Xxxxxxxx

The attribute list is a closed vocabulary

The names that may follow the value are a short fixed set: Path, Domain, Expires, Max-Age, Secure, HttpOnly and SameSite. Some take a value after an equals sign, some stand alone as a bare word. A name outside that set is not a cookie attribute, whatever it looks like.

That gives you one genuinely useful reading. If you see a word after a semicolon that is not on the list, the line has either been edited, truncated, or reassembled from something else. This is one of the few places in this family where close reading pays, and it pays only on the attributes, never on the value.

name=exampleexamplexxxx; Path=/; Secure; HttpOnly

name=exampleexample xxxx, Path=/, Secure

Two faults on one line: a space inside the value, which the alphabet does not allow, and commas where semicolons belong. Both are the signature of a line that was reflowed or retyped rather than copied.

How to check it by eye

What a wrong shape means

A broken cookie line almost always means the line travelled badly. Commas instead of semicolons, a space introduced in the middle of the value, a line wrapped by an editor and pasted back as two, an attribute name mangled by autocorrect. These are transport injuries.

The interesting failure is a truncated value, and it is interesting because it is invisible. If the value should be thirty two characters and you have twenty eight, nothing about the shorter run looks wrong. It uses the same alphabet, it sits in the same place on the line, and only a count reveals it. On this shape, counting characters catches a fault that reading never will.

What a wrong shape does not mean: that somebody tampered with anything. A malformed cookie is overwhelmingly the result of a copy that went through a chat window, a spreadsheet cell, or a text editor with wrapping enabled.

The same value written two ways

A cookie is written once when it is handed out and differently when it is handed back. The form described above, with attributes trailing behind the value, is the form used to establish it. The form used afterwards drops every attribute and carries only pairs: a name, an equals sign, a value, and then a semicolon and a space before the next pair.

The consequence for reading is worth holding on to. A line made of several pairs joined by semicolons is not a cookie with attributes; it is several cookies side by side. If you try to check the words after the semicolons against the closed vocabulary and they are all unfamiliar, you are probably looking at the second form, where those words are names rather than attributes.

The values themselves are identical between the two forms. Nothing is added, abbreviated or re encoded on the way back, so a run counted in one form counts the same in the other.

What a correct shape does not prove

This is the card where the usual warning is at its strongest, because the value was built to be unreadable and it succeeded. Confirming that a cookie is well formed leaves everything open at once.

• Not who it belongs to. The value is opaque by design, which means it contains no account name, no role and no identity you could extract by reading.
• Not whether it is current. A cookie whose stored record was deleted is an exact twin of one that still works.
• Not which site issued it. The name is chosen freely and any site may use any name, so a familiar looking name is not provenance.
• Not that the attributes were honoured. Attributes are instructions to software; the presence of a word on the line does not establish that anything acted on it.
• Not that it is random, long enough, or generated in any particular way. You can measure the length and name the alphabet. There is no third thing.

What this card is not

No guidance is given here on obtaining, moving, storing or reusing any cookie, and none of that belongs on a format reference. This card also stops short of explaining what any attribute causes software to do, since that is behaviour rather than shape. When the same kind of opaque run is written into a URL instead of being stored quietly, see a link with a token inside it.