How V8 stores strings

A string is not always a flat array of characters

The naive model — “a string is a contiguous block of characters” — is only one of V8’s several string representations. V8 picks a representation to make the common operations (concatenation, slicing, comparison) cheap, and only materialises a flat array of characters when it has to. A single JS string value can be any of these HeapObject kinds:

• SeqOneByteString / SeqTwoByteString — the flat case. The characters are stored contiguously right in the object. V8 uses a one-byte (Latin1) backing when every character fits in 8 bits, and a two-byte (UTF-16) backing otherwise — so an ASCII string takes half the memory of one with any non-Latin1 character.
• ConsString — a concatenation node. a + b does not copy characters; it allocates a small node holding pointers to a and b (first and second) and a total length. Concatenation is therefore O(1), and repeated concatenation builds a tree of ConsStrings.
• SlicedString — a substring view. str.slice(i, j) allocates a node holding a pointer to the parent string plus an offset and a length. The substring is O(1) and shares the parent’s characters — but it keeps the entire parent alive.
• ThinString — a forwarding pointer. When a string is internalised (see below) but an old non-internalised copy still exists, the old one becomes a ThinString that just points at the canonical internalised string.
• ExternalString — characters owned by C++ outside the V8 heap (e.g. a source file the embedder kept in its own buffer). V8 holds a pointer to that external storage instead of copying.

The key insight across all five: V8 defers copying characters for as long as possible. Cons and Slice are O(1) precisely because they avoid materialising a flat buffer; the price is a hidden pointer to the original data — which can be enormous. When you pass a string to a native API or index into it, V8 finally pays the copy; the question is whether you want that copy to happen with the full parent attached or after you have broken the chain.

Internalised strings: equality in one cycle

Have you ever wondered how property access stays fast even though property names are strings and string comparison should be O(length)? The answer is internalisation. V8 maintains an internal string table. Identifiers, property names, and string literals are internalised: deduplicated so there is exactly one canonical copy of each distinct string. The payoff is enormous for the engine’s own work — comparing two internalised strings for equality is a single pointer comparison (1 cycle), not a character-by-character scan whose cost scales with length.

This is why property access is fast: the property name in your code and the name stored in the object’s Map are the same internalised string, so the lookup compares pointers. When you create a fresh non-internalised string that equals an existing internalised one (say by reading it from input), and it is then used as a property key, V8 may turn it into a ThinString forwarding to the canonical copy, recovering pointer-equality for future comparisons.

Flattening: the hidden cost of using a ConsString

A ConsString is cheap to build but cannot be used directly for operations that need contiguous characters — most importantly, indexing (str[i], charCodeAt), regex, and passing to C++ APIs. The first time you do something that needs the flat form, V8 flattens the string: it walks the ConsString tree and copies all the characters into a single Seq string, then rewrites the node to point at the flat result.

So the cost of a +-built string is deferred, not free. If you build a huge string with += in a loop and then index it once, you pay one O(n) flatten at that moment. Usually that is fine — but a pathological pattern is building a deep ConsString tree and repeatedly triggering re-flattening, or holding many un-flattened cons trees that bloat the heap. (Modern V8 handles += loops well; the classic advice to always use an array + join matters most for truly enormous builds.)

The memory pitfall: a slice that pins its parent

Back to the Hook. bigString.slice(0, 12) returns a SlicedString that holds a pointer to bigString. As long as that 12-character slice is reachable, bigString cannot be collected — the GC sees a live reference to it through the slice. Keep thousands of tiny slices of a giant file and you keep the giant file (and its backing buffer) entirely alive, even though logically you only wanted a few hundred bytes.

// LEAK: each id is a SlicedString pinning its whole 50 MB source line / buffer.
const ids = lines.map(line => line.slice(0, 12));

// FIX: force a fresh, flat, independent copy that does NOT reference the parent.
const ids = lines.map(line => (line.slice(0, 12) + '').slice());
// or, explicit and clear:
const ids = lines.map(line => {
  const s = line.slice(0, 12);
  return s.repeat(1);            // forces flattening into a standalone Seq string
});

The cure is to force a flatten into a standalone string that copies the characters and drops the parent pointer. Concatenating + '', or any operation that produces a fresh Seq string, breaks the retention chain so the GC can reclaim the parent. The trade is an O(slice-length) copy now in exchange for releasing an O(parent-length) retention — almost always worth it for long-lived small slices.