How to Sideload an Add-On in Firefox

If you’ve been using Firefox for a while, you’ve probably heard the term
“sideloading” tossed around in developer forums and geeky group chats. For a
long time, “sideloading” meant quietly dropping an extension file into a
special folder and having it magically appear in Firefox without the user
doing much of anything.

Today, Firefox plays by slightly different rules. Classic silent sideloading
has been phased out to improve security and give users more control over
what runs in their browser. But that doesn’t mean you can’t install add-ons
from outside the official Firefox Add-ons (AMO) store anymore. You just have
to use a more transparent, user-driven process.

In this guide, we’ll walk through what “sideloading” looks like in modern
Firefox, how to install add-ons from a file, how to temporarily load your
own extension for testing, how self-distribution and enterprise installs
work, and a few real-world lessons learned from people who’ve gone down this
path.

What “sideloading” means in Firefox now

Historically, sideloading was a method where another application (say, a
password manager or corporate tool) would drop an extension into a special
directory, and Firefox would automatically pick it up and install it for all
profiles on that machine. It was convenient… and also a bit scary, because
it meant software could add browser extensions without you explicitly
agreeing in Firefox itself.

Starting with Firefox 73–74, Mozilla removed this style of sideloading from
mainstream builds. Extensions can no longer be silently injected by other
installers and automatically appear in Firefox without user action. Now,
users must explicitly approve extensions inside Firefox.

In everyday language, people still say “sideload” when they:

Install an add-on from a downloaded .xpi file instead of the AMO website.
Temporarily load an unpacked extension for testing via about:debugging.
Use enterprise policies or self-hosted signed extensions instead of the public store.

In this article, we’ll use “sideload” in that modern, practical sense:
installing or using an extension from outside the standard in-browser AMO
flow, but still with your explicit permission.

Before you start: understand Firefox channels and signing

One critical thing to know: modern Firefox requires most extensions to be
signed by Mozilla before they can be installed in Release
and Beta builds. The idea is to reduce malicious or low-quality add-ons and
give users a basic safety net.

Release and Beta: only install signed extensions by
default. Unsigned extensions are blocked.
Developer Edition, Nightly, and ESR (Extended Support Release):
you can disable signature enforcement via an advanced setting if you
really need to run unsigned add-ons, but this is meant for developers and
advanced users.
Dictionaries and some special types: may not require
signing, but most extensions do.

If you’re building your own add-on and want to sideload it into Release
Firefox, the usual path is to package it and submit it for signing (with or
without public listing), then install the resulting signed file.

Option 1: Sideload a signed add-on from a file (.xpi)

The most straightforward modern “sideloading” method is to install an
extension directly from an .xpi file you’ve downloaded.
Think of it as the “Open file…” version of installing from the Add-ons
website.

Step-by-step: install an add-on from a file

Get the add-on file.
This will usually be a .xpi file from a trusted website,
internal company server, or your own build output. Save it somewhere easy
to find, like your Downloads folder.
Open the Add-ons Manager.
In Firefox, click the menu button (three horizontal lines) and select
Add-ons and themes (or press Ctrl+Shift+A /
Cmd+Shift+A on macOS).
Go to the Extensions section.
In the left-hand sidebar, click Extensions.
Use “Install Add-on From File…”
Depending on your Firefox version and UI:
– Click the gear icon (or a more-options icon) in the upper-right of the
Extensions pane.
– Choose Install Add-on From File….
Select your .xpi file.
In the file picker, navigate to where you saved the file, select it, and
click Open.
Confirm the installation prompt.
Firefox will show a confirmation dialog describing what the extension can
do (permissions). If you’re comfortable with it, click
Add.
Manage or pin the add-on.
After installation, you may see a small puzzle-piece icon or extension
icon in the toolbar. You can pin it, hide it, or tweak its settings via
the Add-ons Manager.

Troubleshooting file-based installs

Things don’t always go smoothly. Here are common issues and what they
usually mean:

“This add-on could not be installed because it appears to be corrupt.”
Often this means the file is incomplete, zipped incorrectly, or was
modified after signing. Try downloading it again or re-packaging it.
“This add-on could not be installed because it is not verified.”
The extension likely isn’t signed. On Release Firefox, you must use a
signed extension. Developers should use the signing tools (like
web-ext sign) or install on Developer Edition/Nightly for
testing.
Can’t find “Install Add-on From File…”
On some versions, the menu is hidden behind a gear or more-options icon,
and occasionally UI changes make it less obvious. Make sure you’re in the
Extensions section, not Themes or Plugins.

For most users who just want to install an internal or self-hosted
extension, this method replaces the old “drop file in a special folder”
approach, but with a clear “yes, please install this” step in the browser.

Option 2: Temporarily load an add-on using `about:debugging`

If you’re actively developing an extensionor testing one you don’t want to
fully install yetFirefox lets you temporarily load an unpacked add-on from
a folder. This is perfect for rapid iteration and debugging.

Step-by-step: load a temporary extension

Prepare your extension folder.
Your add-on should be in a directory that contains a valid
manifest.json file and related resources (scripts, icons,
etc.).
Open about:debugging.
In Firefox’s address bar, type about:debugging and press
Enter. Click on This Firefox if you see a sidebar.
Click “Load Temporary Add-on.”
Scroll to the Temporary Extensions section and click
Load Temporary Add-on….
Select manifest.json.
Navigate to the extension folder and select the manifest file (or in some
versions, any file in the folder). Firefox will load the extension
immediately.
Debug and inspect.
In the Temporary Extensions list, you’ll see your add-on. Click
Inspect to open DevTools and debug background scripts,
popups, and other parts of your extension.

The catch? Temporary extensions vanish as soon as you restart Firefox. This
is intentionalit keeps your Release profile from quietly accumulating
random test add-ons.

Use this method when you’re iterating quickly, trying a prototype, or
debugging a sideloaded extension before you go through the signing process.

Option 3: Self-distributing a signed extension

What if you don’t want your add-on listed publicly on the Firefox Add-ons
site, but you still want users to be able to install it easily and safely?
Mozilla supports self-distribution of signed extensions.

The high-level process looks like this:

Package your extension.
Create a standard WebExtension with manifest.json,
JavaScript, icons, etc., and bundle it into an .xpi.
Submit it for signing.
Use Mozilla’s developer hub or CLI tooling (like web-ext sign)
to upload the extension. You can choose to keep it unlisted (not searchable
on AMO).
Download the signed .xpi.
Once it’s processed and signed, you’ll get a signed bundle that can be
installed in Release Firefox without disabling security checks.
Host it where you want.
Put the .xpi file on your own site, an internal server, or a
private download page. Users install it via the Install Add-on
From File… method or by clicking a link that triggers an install
prompt.

This is essentially “sideloading with Mozilla’s blessing.” You keep
distribution private or semi-private, while still meeting Firefox’s signing
and policy requirements.

Option 4: Enterprise-style sideloading with policies

In managed environments (corporate, education, government), administrators
often need a way to deploy specific extensions to a fleet of machines
without asking every user to go through the Add-ons Manager manually.

Firefox supports this through enterprise policies, which
can be configured via:

Group Policy (GPO) on Windows
Configuration profiles on macOS
A policies.json file in a distribution folder

With the right policy settings, admins can:

Install specific extensions automatically from URLs or local paths.
Lock extensions so users can’t disable or remove them.
Control which add-ons are allowed or blocked entirely.

This is still a form of sideloading, but it’s controlled and explicit,
designed for IT-managed environments rather than casual home use. If you’re
a regular user, you won’t normally touch these settingsbut if your company
“magically” installs an extension in Firefox, this is probably how they’re
doing it.

Security, policies, and blocked add-ons

Firefox enforces a set of add-on policies around privacy, security, and
user experience. In some cases, Mozilla can blocklist an
extension that’s found to be malicious or severely problematic. When that
happens, the add-on can be disabled or prevented from running even if it was
sideloaded or self-distributed.

This can be surprising if you wrote the extension yourself and only use it
locally. If your add-on triggers policy checks (for example, suspicious
behavior or mis-declared data collection), Firefox might flag it. Following
official development and distribution guidelines helps avoid unpleasant
surprises.

Bottom line: sideloading gives you flexibility, but it doesn’t exempt you
from Firefox’s security rules. Treat that as a feature, not a bug.

Common sideloading questions and gotchas

“Can I permanently install an unsigned add-on in Release Firefox?”

In short, nonot without doing something that Firefox is specifically
designed to prevent. Release and Beta builds enforce signing for good
reasons. If you really must run an unsigned extension, use Developer
Edition, Nightly, or ESR and toggle signature enforcement off in
about:config. Just remember: you’re trading safety for
flexibility.

“Why does my temporary add-on keep disappearing?”

That’s expected. Anything loaded via about:debugging as a
temporary extension is wiped out on browser restart. This keeps your regular
profile clean while you experiment. When you’re ready for something more
permanent, sign and install from a file.

“Firefox says my extension violates policies. What now?”

If Firefox disables your add-on for “violating policies,” review its
behavior against the latest add-on policiesespecially around data
collection, remote code, and permission scopes. You may need to adjust your
code, permissions, or privacy disclosures and then re-submit for signing.

“Is sideloading safe?”

It’s as safe as the source you trust. A signed extension is not a magic
guarantee of goodness, but it does add friction for malware. If you’re
sideloading something from a random forum post, you’re taking a risk.
Always:

Check who created the add-on and where it’s hosted.
Review requested permissions carefully.
Prefer signed and reviewed extensions when possible.

Best practices for sideloading add-ons in Firefox

Stick to signing whenever possible.
Even if you self-distribute, using Mozilla’s signing system gives you
compatibility with Release Firefox and reduces random install issues.
Use Developer Edition or Nightly for heavy experimentation.
If you’re constantly loading temporary extensions, debugging, or testing
new APIs, use a separate profile in a developer-focused build.
Keep permissions minimal.
Whether your add-on is public or private, request only the permissions you
truly need. Overreaching permissions are a red flag for users and
reviewers.
Document your installation steps for users.
If you’re sharing a sideloaded extension with a team, give them a simple
checklist (with screenshots, if possible) for installing from a file or
enabling it.
Monitor for breakage after Firefox updates.
Sideloaded extensions, especially internal or niche ones, can be the first
casualties when APIs or behaviors change. Test early on new versions.

Real-world experiences: what it’s like to sideload Firefox add-ons

Sideloading an add-on in Firefox sounds like a dry technical task, but in
real life it shows up in all sorts of scenariosfrom students hacking their
school portals to IT admins trying to deploy tools quietly without causing
chaos.

Imagine a college student who’s been using a custom extension for years to
wrangle a clunky campus portalauto-filling forms, cleaning up messy HTML,
making grades easier to read. One day, the extension disappears from the
official Firefox add-on site. The developer sends over a ZIP file and says,
“Just install it manually.” The student discovers temporary loading via
about:debugging and spends months re-loading the extension
every time Firefox restarts. Annoying? Absolutely. But it’s also a perfect
lesson in why signing and proper distribution matter. Once the developer
learns how to get the extension signed and self-distributed, it becomes as
easy to install as any other add-onjust with a slightly more manual first
step.

In a corporate setting, sideloading looks very different. Think of an IT
team responsible for hundreds or thousands of employees. They use Firefox as
a standard browser and need a couple of critical extensions: a security
agent, maybe a single sign-on helper, maybe a productivity tool. Asking
every employee to visit the Add-ons Manager and click through permission
prompts is a recipe for support tickets. Instead, the team sets up
enterprise policies. With a bit of JSON and group policy magic, extensions
appear in Firefox automatically, locked so users can’t uninstall them. From
the worker’s perspective, the extension is “just there.” Under the hood,
though, it’s still a form of controlled sideloadingjust with formal
policies and audit trails.

Developers have their own love–hate relationship with sideloading. On the
one hand, temporary loading via about:debugging is amazing.
You tweak your code, reload the extension, and instantly see what breaks or
improves. You can attach DevTools, inspect background scripts, and log to
your heart’s content. On the other hand, if you’re lazy about packaging and
signing, you can easily end up with an add-on that only runs in your dev
browser and goes nowhere else. Many devs eventually adopt a workflow where
they use web-ext or similar tools to automate signing and
packaging. That way, their “sideloaded” extension is always one step away
from being safely installed on a clean Release profile.

Then there are the people caught in the middlefolks who aren’t full-time
developers but are “dangerous enough” with code to write a custom
extension. They often treat sideloading as a personal power tool: a way to
make the browser truly theirs. They might roll a tiny extension that adds a
button for a niche workflow, or that cleans up a proprietary internal
dashboard. For these users, learning the basics of temporary loading and
file-based installs is empowering. Once they understand that Firefox isn’t
trying to kill their creativityjust to keep them safethey usually find a
comfortable balance: experiment in a dev profile, sign what matters, and
install it properly when it’s ready.

The pattern across all of these stories is the same: sideloading isn’t a
shady backdoor anymore; it’s a more transparent, intentional way of running
extensions that don’t live in the main add-on store. Yes, there are a few
more clicks than there used to be. But in exchange, you get clearer
permission prompts, better security, and a browser that’s far harder for
random software to hijack behind your back. Once you understand the
workflowstemporary loading, file-based installs, self-distribution, and
enterprise policiessideloading in Firefox becomes just another tool in your
toolbox, not a mysterious hack.

Conclusion

Sideloading add-ons in Firefox has evolved from a quiet “drop a file in a
folder” trick into a set of safer, more explicit workflows. Whether you’re
installing a trusted .xpi file from your company, testing your
own extension with about:debugging, or deploying tools across
an organization with policies, Firefox gives you multiple ways to run
extensions that don’t live in the public store.

The key is to respect signing, pay attention to permissions, and choose the
right method for your situation. Do that, and you’ll get the power of
sideloading without turning your browser into the Wild West.