We scanned 13 real Shopify stores and found 79 conflicts. Three scored 0/100. Here's exactly what Shopify theme conflicts are, why they happen, how they show up in the wild, and how automated diagnostics catch them before your merchants file a support ticket.
A Shopify theme conflict happens when CSS rules, JavaScript, or DOM structure from an installed app interfere with the merchant's active theme — or when the theme interferes with the app. The result is broken UI: app widgets that disappear, pop-ups that hide behind sticky headers, cart drawers that refuse to open, or product page elements that overlap incorrectly.
Shopify's architecture is inherently collision-prone. Every app injects scripts and stylesheets directly into the theme's DOM. There's no sandboxing between apps and themes in standard Liquid/storefront code. When a theme sets overflow: hidden on a parent container, it clips any app widget inside it — regardless of how carefully the app is built.
The problem is compounded by the sheer volume of themes. Shopify merchants can use any of thousands of themes from the Theme Store, third-party developers, or custom builds. Every theme makes different assumptions about CSS specificity, z-index layers, and JavaScript execution order. A widget that works perfectly on Dawn may be completely invisible on Impulse.
Key Terms
Conflicts aren't bugs in your app or bugs in the theme — they're integration failures. Neither the app developer nor the theme developer anticipated the other's code. The merchant is stuck in the middle, and their support ticket lands on whoever they installed most recently.
Most app developers only see conflicts after merchants report them. By then, the merchant is already frustrated, has probably tried reinstalling the app, and has lost revenue from broken conversion flows. Here's what these failures actually look like in the wild:
The merchant reports "your app isn't showing up." You check your dashboard — the app is installed, the script is loading, the widget should be there. You open their store in a browser and it's gone. When you open DevTools, you find it: the widget is present in the DOM, but a parent container has overflow: hidden with a fixed height, and the widget rendered below that boundary. The theme clipped it off the screen.
Your app shows a upsell pop-up after "Add to Cart." On most stores it works. On this merchant's store, the pop-up appears but immediately disappears behind the sticky cart drawer. The theme's cart drawer has z-index: 1000000. Your pop-up has z-index: 9999. The pop-up loses.
Your app renders a review widget with specific typography and button styles. On the merchant's store, your widget looks completely different — wrong font, wrong button color, wrong padding. The theme is using non-scoped CSS selectors like .button or p without namespacing, and those global rules override your app's styles.
Everything looks fine on desktop. On mobile, your widget is completely missing. Turns out the theme applies display: none to a parent container at a specific breakpoint, and your widget lives inside that container. The theme intended to hide a sidebar — your widget was collateral damage.
Why These Are Hard to Find Without Automation
None of these failures throw JavaScript errors. None trigger 500 responses. Your monitoring tools show everything is healthy. The only signal is a merchant's support ticket — usually days after install, from a store you've never seen before, running a theme version you've never tested against.
Shopify theme conflicts fall into four mechanical categories. Understanding each one is the first step to diagnosing and preventing them.
Shopify themes often use very high z-index values on persistent UI elements — sticky headers, cart drawers, cookie banners, live chat widgets. When your app creates a modal, overlay, or pop-up, it needs to be higher in the stacking context than all of these. The problem: different themes use wildly different z-index ranges, from 100 to 2147483647 (the maximum 32-bit integer).
/* Theme: cart drawer sits at z-index 1000000 */
.cart-drawer {
z-index: 1000000;
position: fixed;
}
/* Your app: upsell modal at z-index 9999 — loses every time */
.app-upsell-modal {
z-index: 9999; /* buried under cart drawer */
position: fixed;
}
Detection signal: PreFlight checks z-index values on fixed/absolute positioned elements across the rendered DOM and flags when theme elements have z-index values that would obscure app UI components.
When a parent element has overflow: hidden or overflow: clip, any child element that renders outside its boundaries is visually cut off — even if it has a high z-index. Theme developers use overflow:hidden for good reasons: preventing horizontal scrollbar bleed, constraining slide-in animations, clipping decorative background shapes. But app widgets injected inside those containers are invisible victims.
/* Theme: section wrapper clips content */
.featured-collection {
overflow: hidden;
height: 600px;
}
/* App widget injected inside .featured-collection renders below 600px */
/* Result: widget is completely clipped and invisible to users */
Detection signal: PreFlight traces the ancestor chain of app elements, checking for overflow:hidden ancestors with fixed dimensions that would clip the rendered widget.
Many older Shopify themes use low-specificity selectors like p, .button, a, form input without namespacing. These global selectors bleed into every element on the page — including app-injected UI. Your carefully styled widget inherits the theme's font family, button color, form padding, and link decoration whether you want it to or not.
/* Theme: global button styles with no scoping */
.button, button, [type="submit"] {
background-color: #1a1a1a;
border-radius: 0;
font-family: 'Playfair Display', serif;
letter-spacing: 0.2em;
}
/* App's button styles use .app-widget .button — same specificity */
/* Whichever loads last in the stylesheet wins */
Detection signal: PreFlight compares computed styles on app elements against the app's expected styles, flagging deviations that match known theme global selector patterns.
Themes sometimes conditionally hide sections — for loading states, mobile-only hiding, or page-type-specific logic. When an app widget is injected into one of these conditionally hidden elements, it inherits the hidden state. The widget is in the DOM, the JavaScript initialized correctly, but the user can't see it because a grandparent element has display: none or visibility: hidden.
/* Theme: section hidden on mobile */
@media (max-width: 768px) {
.product-sidebar {
display: none;
}
}
/* App injects review widget into .product-sidebar */
/* Result: reviews invisible on mobile, 50-70% of merchant traffic */
Detection signal: PreFlight checks getComputedStyle on app elements and their ancestors, looking for inherited hidden states that would render the element invisible.
Theory is one thing. Here's what we actually found when we pointed PreFlight at 13 real Shopify stores across different niches, themes, and app stacks.
Three stores scored 0/100. That means PreFlight detected critical conflicts across every single check category: the app elements weren't visible, z-index stacking was broken, overflow was clipping content, CSS conflicts were present, and third-party app interference was detected — all at once. These stores were actively losing revenue from broken conversion flows while looking healthy from the server side.
The three stores that scored 0/100 all had one thing in common: multiple apps installed that each tried to add UI elements to the same DOM regions. Each app made assumptions about z-index and overflow that were valid in isolation — but collapsed when stacked on top of each other. One store had a sticky add-to-cart bar (z-index: 99999), a live chat widget (z-index: 9999999), and a size guide pop-up app (z-index: 1000) — all fighting over the same screen real estate. The lowest z-index app's pop-up was completely unreachable.
None of these merchants had filed a support ticket. That's the dangerous part: users don't always report broken UI — they just leave. The store loses the conversion silently. Without automated scanning, these conflicts can persist for months.
The Invisible Revenue Problem
If a pop-up upsell widget is broken on a store doing $50k/month in revenue, and the upsell converts at 3%, that's $1,500/month in missed revenue — per store. Multiply across your app's merchant base and the math gets serious fast. PreFlight catches these conflicts at install time, before the revenue is ever lost.
PreFlight doesn't read static HTML — it fetches and renders the live storefront the same way a browser does, then inspects the computed DOM for the six conflict categories that cause 95% of real-world issues.
PreFlight scans for known app widget selectors, script tags, and pixel signals. If an app is installed (per the Shopify API) but its UI elements aren't present in the rendered DOM, that's a critical failure — something is blocking initialization entirely.
Uses getComputedStyle to check display, visibility, and opacity on the element and all its ancestors. Catches cases where a grandparent container is hidden by the theme, making the app widget inherit that hidden state.
Catalogs all positioned elements with z-index values above a threshold. Compares them against app widget positions on screen to identify cases where theme UI (sticky headers, cart drawers, nav overlays) is rendered above app-injected elements in the same viewport region.
Traverses the ancestor tree of app elements, flagging overflow: hidden or overflow: clip ancestors with constrained dimensions. Also detects clip-path and CSS masking that would cut off app UI.
Compares computed styles on app elements against expected values, surfacing cases where theme global selectors have overridden app-defined properties. Flags unscoped theme selectors in loaded stylesheets that match app component class names.
Detects other Shopify app scripts running on the page and checks for known conflict patterns between popular app combinations — particularly around z-index layering, script loading order, and global event listener conflicts.
Each check is weighted by severity. Critical issues (invisible widget, complete z-index burial) subtract more from the score than warning issues (slight style deviation, mild CSS conflict). A store with 1 critical issue scores lower than a store with 5 warning issues.
No account required. Results in <15 seconds.
Knowing the cause makes the fix straightforward. Here are the four canonical fixes — one per conflict type.
Any modal, overlay, or pop-up that needs to be on top of everything should be appended directly to document.body, not injected into a theme section. document.body is always the highest stacking context root. Use position: fixed with a z-index high enough to clear the top 1% of theme values.
// Append modal to body — escapes all theme stacking contexts
const modal = document.createElement('div');
modal.className = 'my-app-modal';
modal.style.cssText = 'position:fixed;top:0;left:0;width:100%;height:100%;z-index:2147483640;';
document.body.appendChild(modal); // ← always body, never a theme section
For widgets that must render inside the page flow (not fixed/floating), Shadow DOM creates a true CSS boundary. Theme styles don't pierce the shadow boundary. Your widget's styles don't affect the theme. Overflow:hidden on an ancestor still clips the shadow host element's box, but your internal layout is protected.
const host = document.getElementById('my-app-container');
const shadow = host.attachShadow({'{'} mode: 'open' {'}'});
shadow.innerHTML = `<style>/* scoped styles here */</style><div class="widget">...</div>`;
// Theme CSS cannot override styles inside the shadow root
Prefix every CSS class with a unique app namespace. Never use generic selectors like .button or p at the root of your stylesheet. Use a CSS reset scoped to your namespace to neutralize any inherited theme styles.
/* WRONG: no namespace, bleeds into everything */
.button {'{'} background: #4ade80; {'}'}
/* RIGHT: fully namespaced, isolated */
.myapp-v2__button {'{'} background: #4ade80; {'}'}
.myapp-v2__wrapper * {'{'} box-sizing: border-box; font-family: inherit; {'}'}
When a theme uses JavaScript to conditionally show/hide sections (lazy loading, AJAX page transitions), your widget may initialize before the container is visible. Use a MutationObserver to detect when the container becomes visible and re-render.
const observer = new MutationObserver(() => {'{'}
const container = document.getElementById('my-app-target');
if (container && getComputedStyle(container).display !== 'none') {'{'}
initializeWidget(container);
observer.disconnect();
{'}'}
{'}'});
observer.observe(document.body, {'{'} childList: true, subtree: true, attributes: true {'}'});
Enter any Shopify store URL and get a full diagnostic in under 15 seconds. PreFlight checks all 6 conflict categories and returns an actionable score with specific fixes.
Run a Free Shopify Theme Conflict ScanNo sign-up. No credit card. Instant results.