Post History

Having looked up how Snappy compression works, I'm going to upgrade my comment to an answer as I'm almost certain this is what's happening.

Based on the Firefox source code, it [inserts](https://github.com/mozilla-firefox/firefox/blob/main/dom/localstorage/ActorsParent.cpp#L3720) [`LSValue`s](https://github.com/mozilla-firefox/firefox/blob/main/dom/localstorage/LSValue.h#L37) which are strings with some meta-information specifying how they should be stored. Relevant here is the `CompressionType` which can either be `UNCOMPRESSED` or `SNAPPY`. This gets stored in the `data` table as the `compression_type` field with a value of 1 indicating Snappy compression.

[Snappy compression](https://en.wikipedia.org/wiki/Snappy_(compression)) is a relatively simple byte-oriented, dictionary-based compression algorithm. The compressed output consists of a sequence of elements which are either uncompressed parts of the input, or references to spans of decompressed output. The "opaque binary sequences" you're seeing are almost certainly the tags for the elements (which is all there is of a reference element).

To specifically answer your question, to read the `value` field of a row in the `data` table, you need to take into account the `conversion_type` field and the `compression_type` field. If the `compression_type` field is 1, then the value needs to be decompressed with the Snappy algorithm first. If it is 0, then it is not compressed. After that, the `conversion_type` indicates whether the data is stored as UTF-8 or UTF-16. If `conversion_type` is 1 then the data is stored as UTF-8, otherwise it's stored as UTF-16.