How to Use Storage in Web Extensions

By  on  

Working on a web extension is an interesting experience -- you get to taste web while working with special extension APIs. One such API is storage -- the web extension flavor of persistence. Let's explore how you can use session and local storage within your Manifest V3 web extensions!

Enabling Extension Storage

The extension storage API isn't available by default. To enable the storage API, you need to cite it in the manifest.json file of your extension:

{
  // more....
  "manifest_version": 3,
  "name": "__MSG_appName__",
  "permissions": [
    "storage",
    // more....
  ],
  // more....
}

Adding storage to the permissions array, which is a top level manifest.json key, provides session and local storage capabilities to your extension.

Get, Set, and Remove Storage Values

Much like traditional localStorage and sessionStorage APIs, extension storage provides get, set, and remove operations:

// set
await chrome.storage.session.set({ name: "David", color: "green" });

// get 
const { name, color } = await chrome.storage.session.get(["name", "color"]);

// remove
await chrome.storage.session.remove(["name", "color"]);

A few things to note:

  • get requires an array argument, not a single value like localStorage and sessionStorage
  • set needs to be an object format
  • remove is also an array, much like get
  • You can use chrome.storage.local or chrome.storage.session depending on how
  • All of the extension storage API methods are promise-based, with await or callback formats

Clear All Storage

In the event that you want to clear all data for local or session storage, there's a clear method:

await chrome.storage.session.clear();

Using clear is effective but you'll want to be sure that you do truly want to clear everything -- clear could become a maintenance issue.

Storage is an essential part of most web extensions. While the API is simple, the async format and method names are different.

Recent Features

  • By
    JavaScript Promise API

    While synchronous code is easier to follow and debug, async is generally better for performance and flexibility. Why "hold up the show" when you can trigger numerous requests at once and then handle them when each is ready?  Promises are becoming a big part of the JavaScript world...

  • By
    How I Stopped WordPress Comment Spam

    I love almost every part of being a tech blogger:  learning, preaching, bantering, researching.  The one part about blogging that I absolutely loathe:  dealing with SPAM comments.  For the past two years, my blog has registered 8,000+ SPAM comments per day.  PER DAY.  Bloating my database...

Incredible Demos

  • By
    LightFace:  Facebook Lightbox for MooTools

    One of the web components I've always loved has been Facebook's modal dialog.  This "lightbox" isn't like others:  no dark overlay, no obnoxious animating to size, and it doesn't try to do "too much."  With Facebook's dialog in mind, I've created LightFace:  a Facebook lightbox...

  • By
    Using MooTools For Opacity

    Although it's possible to achieve opacity using CSS, the hacks involved aren't pretty. If you're using the MooTools JavaScript library, opacity is as easy as using an element's "set" method. The following MooTools snippet takes every image with the "opacity" class and sets...

Discussion

  1. This is great. But this it work in both Firefox and Chrome extensions?

    In my experience, if you store something in storage.session on FF – once the extension gets “inactive” (Manifest V3 feature), it’s lost – but in Chrome it persist. So storage.session on FF is worthless. Do you have the same experience?

Wrap your code in <pre class="{language}"></pre> tags, link to a GitHub gist, JSFiddle fiddle, or CodePen pen to embed!