Protect what matters – even after you're gone. Make a plan for your digital legacy today.
Forum Discussion
Solved
1Password Chrome extension is incorrectly manipulating <code> blocks
The latest 1Password Chrome extension is incorrectly manipulating the DOM within <code> blocks on static pages. It looks it's using prism.js to try to add syntax highlighting to <code> blocks on the entire page. If you're using a static site generator to highlight code with a different library, it causes the display to break.
Example: mkdocs, a popular documentation tool
If you view the documentation for customizing Mkdocs material (https://squidfunk.github.io/mkdocs-material/customization/) with the extension enabled, you'll see that the YAML example at the top is not highlighted (it should be).
Under the hood, if you inspect its DOM, you can see that it's been rewritten with prismjs classes.
If you disable the extension, it is highlighted:
This is likely to impact a number of documentation sites in the tech community.
Hey everyone! I want to thank everyone who called our attention to this and explain what happened and what we’re doing about it.
What happened: Prism.js is a syntax-highlighting library we use for our Labs Snippets feature. While optimizing our build to reduce bundle size, we unintentionally bundled Prism.js into the extension in a way that caused it to run on pages where it shouldn’t, which interfered with code formatting on certain sites. We apologize for the inconvenience this caused.What we’re doing about it: We’ve completed the fix and submitted it to the Chrome Web Store, along with Firefox, Edge, and our other supported extension storefronts. Rollout timing depends on each store’s review process, but we expect it to land over the next few days.
We want to emphasize that vault security was not impacted. At 1Password, protecting our customers’ privacy, passwords, and credentials is our highest priority.
We’ll be publishing a postmortem covering what went wrong, the timeline, and the concrete changes we’re making to how we build and release future browser extension updates.
52 Replies
Just to update my earlier note: as of today (2025-12-24), Firefox on macOS is now using v.8.11.23.2 of this extension, and it has the same bug as the Chrome extension. :-(
We’ve run into the same issue described in this thread on our production website.
We use Shiki as a server-side code highlighter for code blocks (static HTML generated on the server and sent fully rendered to the browser). The code blocks are initially rendered correctly, but shortly after page load the Chrome extension mutates the DOM inside <code> elements. As a result, the internal structure generated by Shiki (for example, line wrappers and nested spans) is rewritten, and the code formatting breaks.
We’ve verified that:
The HTML is already fully highlighted on the server (no client-side highlighting).
The issue does not reproduce in Incognito mode with extensions disabled.
The DOM structure inside <code> differs between normal mode (with 1Password enabled) and Incognito mode.
data-1p-ignore / data-1password-ignore do not prevent this behavior in our case.
Because our site receives a large volume of traffic, this issue affects a significant number of users, and we need to ship a fix as soon as possible, even if it must be handled entirely from our side as a workaround.
With that in mind, we have two key questions:
Is there any supported or recommended way, from the website’s codebase, to prevent the 1Password Chrome extension from mutating the contents of <code> blocks?
For example, specific attributes, markup patterns, or configuration that the extension explicitly respects.What is the rationale for the Chrome extension mutating the DOM inside <code> elements at all?
From a website’s perspective, <code> represents static, non-interactive content, and DOM mutation here can break widely used syntax highlighters that rely on a stable internal structure.We understand that browser extensions operate with elevated privileges and that this may be a bug rather than intended behavior.
Thanks in advance for your time, and happy to provide a minimal reproduction if that’s helpful.
I've actually just created a fix in my situation. I'm using Phiki which is a PHP-port of Shiki you are using. But in my case, i created a transformer that completely removes the `language-javascript"` class from the output.. this is what Prism.js uses to latch on and convert the code blocks. Not sure what you would need to do in Shiki exactly, but this is what i do in PHP:
<?php namespace Grav\Plugin\Codesh; use Phiki\Phast\ClassList; use Phiki\Phast\Element; use Phiki\Transformers\AbstractTransformer; /** * Transformer to prevent Prism.js from re-highlighting Phiki output. * * Removes 'language-*' and 'lang-*' classes that Prism uses to identify code blocks. * The original language is preserved in the data-language attribute. * * This addresses an issue where browser extensions (like 1Password) inject Prism.js * which strips server-side syntax highlighting and replaces it with class-based tokens. * * @see https://www.1password.community/discussions/developers/1password-chrome-extension-is-incorrectly-manipulating--blocks/165639 */ class PrismDefenseTransformer extends AbstractTransformer { /** * Modify the <pre> tag to remove Prism-triggering class names. */ public function pre(Element $pre): Element { $classList = $pre->properties->get('class'); if ($classList instanceof ClassList) { $newClasses = []; foreach ($classList->all() as $class) { // Remove language-* and lang-* classes that Prism targets if (!str_starts_with($class, 'language-') && !str_starts_with($class, 'lang-')) { $newClasses[] = $class; } } $pre->properties->set('class', new ClassList($newClasses)); } return $pre; } /** * Post-process the HTML to ensure no language classes remain. * This is a backup in case the pre() method doesn't catch everything. */ public function postprocess(string $html): string { // Remove language-* and lang-* classes from <pre> tags $html = preg_replace_callback( '/<pre\s+([^>]*?)class="([^"]*)"/', function ($matches) { $beforeClass = $matches[1]; $classes = $matches[2]; // Remove language-* and lang-* classes $classes = preg_replace('/\b(language|lang)-\S+\s*/', '', $classes); $classes = trim(preg_replace('/\s+/', ' ', $classes)); return '<pre ' . $beforeClass . 'class="' . $classes . '"'; }, $html ); return $html; } }In fact, 1Password Extension should not inject Prism.js into the other webpages in the very first place!
On Safari 26.1, for example, referring to the page, https://en.wikipedia.org/wiki/Template:HTML_lists, with the 1Password Safari extension disabled, all of the list types in the table are linked (in code-formatted text, following the "{{" template opening syntax). For instance, under "Horizontal list", the text "hlist is linked: `{{https://en.wikipedia.org/wiki/Template:Hlist `.
With the 1Password Safari extension enabled, none of the links in the sample code in that table are linked. After enabling the 1P Safari extension, all of the links in that table are stripped from the HTML of the page.
Is the Javascript and/or CSS of the 1Password Safari extension having class or ID collisions with the links in that page? This isn't the only place I've seen the bug (anything related to Wikpedia's "tlx" -style templates seem to have the same problem.
I have disabled all other extensions in Safari and isolated the issue to just the 1Password Safari extension.
This also happens in Firefox on Linux. With the 1Password extension (8.11.23.2) disabled, the page loads as it should; as soon as I switch it back on, the links disappear immediately. The extension changes this
<code>{{<a href="/wiki/Template:Hlist" title="Template:Hlist">hlist</a>|item1 |item2 }}</code>to this
<code class="language-none">{{hlist|item1 |item2 }}</code>Edit – I think it's this bug: 1Password Chrome extension is incorrectly manipulating <code> blocks | 1Password Community
I've just spent hours trying to track down this very issue with a new server-side syntax highlighting plugin i'm writing. It was working fine, then a couple of days ago, noticed the behavior where it was highlighting correctly, then quickly rewrites to this monochrome version. I thought some other JS was injecting prism.js, and eventually got desperate enough to disable plugins.. I was shocked to find it was 1password, and not some of the json highlighter plugins i had installed.
Please fix this asap, it's a huge pain, and causing much hassle. I have had to switch 1password to activate on 'click' which is a royal pain, but there's no other way of turning it off apparently.
FYI, tried nightly 1Password release, no dice.. still a problem
Seeing this also in a number of other sites (including my own). One example (not my own):
https://mac.install.guide/terminal/path
EDIT: Am also seeing the same occur with the 1Password extension in Safari on both macOS and iOS. Doesn't seem to affect Firefox (macOS, at least), interestingly.
EDIT #2: The lack of the problem is Firefox is likely because of differing versions in the extensions themselves. While I have each browser's 1Password extension set to allow automatic updates, the one for Firefox is at only v.8.11.16.35 (October 28, 2025), while the one for Chrome is at v.8.11.22.27 (December 15, 2025); these versions appear to be the latest available for each browser. As for the Safari extension, it would seem to be v.8.11.22 from approximately one week ago (Apple's App Store shows only relative dates, such as "1w ago").
- 1P_Blake
Community Manager
Thanks for flagging this joeRinehart! We've been able to reproduce this internally and the team is actively investigating the syntax highlighting issue and working on a fix.
Can confirm. Anybody find a workaround? Is there a way to manually install an old extension version? I need to disable it for now, working in confluence whole day and this is just a mess right now :( No highlighting, linebreaks damages, escape sequences broken :(
Same problem here with Fractl's HTML and View panels. Not only is the highlighting gone, but all whitespace is collapsed, which makes those views much harder to use. In Fractl, I can see a flash of highlighted, formatted code before it collapses into a long string.
Not clear to me why a password manager extension is fiddling with code views to begin with. 1PW please fix this ASAP.We've also found a problematic display issue with the 1password browser extension in Chrome (and other Chromium based browsers like Brave). Please find the details below.
Description of the issue
When the 1password browser extension in the Chrome browser (or Brave) is installed and active, the font color of code snippets is almost invisible.
Steps for Reproduction
- Install the official 1password extension from the Chrome Webstore
- Go to an example documentation page with code snippets: https://qdrant.tech/documentation/concepts/points/
- Observe, that code snippets are almost unreadable, because the font color and the actual rendering of the snippet is very different. It seems the rendering doesn't take place.
Expected behavior
- The code snippets on the Qdrant Documentation are clearly visible with the right font color
- Please find a screenshot of a Chrome browser with the 1password extension inactivePlease let us know if and when this can be fixed within your Browser extension or how we can potentially mitigate this on our end.
Thanks in advance!Tim
This issue causes code blocks in mdbook to be rendered incorrectly. Lines that are supposed to be hidden are visible, and syntax highlighting is disabled. Disabling the 1Password extension fixes the issue. First reported here:
https://github.com/rust-lang/mdBook/issues/2994
Sample page for testing:
https://rust-lang.github.io/beyond-refs/reborrow/custom-mut.html
This issue causes code blocks to be incorrectly rendered in mdbook. Lines that are supposed to be hidden are unhidden and syntax highlighting is lost. Disabling the extension fixes the issue. First reported here:
https://github.com/rust-lang/mdBook/issues/2994
Sample page for testing:
https://rust-lang.github.io/beyond-refs/reborrow/custom-mut.html
