1Password Chrome extension is incorrectly manipulating blocks

I was looking https://shiki.style/guide/install , an NPM package which provides syntax highlighting and showing detail hovering on keywords. It is expected to be shown and work like this

but is actually shown like this when using a beta or nightly browser extension. There's no issue on normal one.

• OS: macOS 26.2 (25C56)
• Browser: Brave v1.85.111

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 inactive

Please 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

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.

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 :(

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.

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").

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.

@1P_Blake Do we have an ETA on this?

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.

@1P_Blake 

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.