The Shopify Login Popup Is Gone and What Replaces It

Someone paid for a login experience that felt like part of your store. A modal opened over the page, the customer signed in without leaving, and the cart stayed where it was. On customer accounts that is gone. The customer is redirected to a Shopify-hosted page you cannot open in a popup and cannot style beyond branding. Here is what you lost, what you can recover, and what to stop trying to rebuild.

What actually changed

Legacy customer accounts rendered inside your theme through Liquid templates in the customers folder. Because the login form was yours, you could put it anywhere, including a modal in the header, and style it exactly like the rest of the store.

Customer accounts move sign-in onto Shopify-hosted pages. The customer leaves your storefront, authenticates, and comes back. You control branding settings and you can extend the account area with UI extensions, but you do not control the page itself, and you cannot intercept the redirect to keep the customer on your site.

That is a real loss of control and it is worth acknowledging plainly rather than pretending the replacement is equivalent.

Why Shopify did it

Not to annoy you, and understanding the reasoning helps you predict what will and will not come back.

Authentication rendered inside a merchant theme is authentication running in code Shopify does not control, on pages that can be modified by any app or developer with theme access. Moving it to hosted pages means the sign-in flow is consistent, is patched centrally, and cannot be broken by a theme edit. It also makes passwordless codes, passkeys and social login work uniformly across every store.

The practical consequence is that the modal is not coming back. Any effort spent trying to recreate it is spent fighting the architecture.

What you can still control

Branding on the hosted pages. Logo, colours and typography settings so the pages read as yours rather than generic. Most stores never configure this properly and then complain the pages look unbranded. Do this first, because it is free and it addresses most of the visual objection.

The account area itself, through UI extensions. This is where the real capability sits, and there are three kinds of placement. Block targets are positions merchants can arrange in the accounts editor. Full page targets give you custom pages with dedicated routes inside the account area. Static targets sit at fixed locations tied to specific features.

Full page targets are the underused one. If you needed a custom dashboard, a membership area, or a returns portal, that can live inside customer accounts as its own page rather than being crammed into a block.

Data. Extensions can read metafields on cart, customer, order, company, companyLocation, product, shop and variant, so an extension can be genuinely personalised rather than static.

The constraints you need to know before scoping

These are the numbers that decide whether an idea is buildable, and they catch teams who scope before checking.

• 64 KB. Your compiled UI extension bundle cannot exceed it. That rules out heavy component libraries and large dependencies, and it is the constraint most likely to derail an ambitious build.
• Web Worker execution. Extensions run in an isolated sandbox with no access to window or the DOM. Anything assuming direct page manipulation does not apply.
• Network access is opt in and reviewed. You declare network_access = true in capabilities and request approval through the Partner Dashboard, and your server must return Access-Control-Allow-Origin: *.
• Up to 20 settings per extension.
• Three extensions per block target location. If two apps already occupy a slot, you have less room than you think.

The 64 KB limit deserves emphasis. It is not a soft guideline, it is enforced at deployment, and it is the reason a design that assumed a full frontend framework has to be rethought rather than trimmed.

If you genuinely need the login inside your storefront

There is one supported route and it has a hard gate.

With a headless storefront you control the entire front end and authenticate through the Customer Account API. That gives you back control of where and how sign-in appears, at the cost of owning your whole frontend. Our comparison of Hydrogen and Liquid covers whether that trade is worth making, and for most brands the answer is no if login styling is the only reason.

Separately, on Shopify Plus, connecting your own identity provider replaces the default sign-in experience entirely. That is the route brands take when identity is shared across a store, an app and another platform. We covered it in customer accounts and where Auth0 fits.

What we would not do is attempt to recreate the modal on a standard Liquid store. Multipass, which people reach for here, works only with legacy customer accounts and those are deprecated.

A more useful way to think about it

The modal was solving a conversion worry: that sending someone away from the page loses them. Worth checking whether that is actually happening to you rather than assuming.

Most customers sign in once and stay signed in. The redirect happens rarely per customer, and passwordless sign-in is faster than remembering a password, which cuts the other way. If your returning customer rate held steady after upgrading, the redirect is not costing you what you feared, and the money is better spent on the account area than on the login page.

Check it rather than argue about it. Compare your returning customer rate for the eight weeks before the upgrade against the eight weeks after, and compare the share of orders placed by signed-in customers over the same periods. If both held, the redirect is not your problem and you can close the question. If either dropped, look at email deliverability before blaming the redirect, because a login code that never arrives produces exactly the same symptom and is far more common.

Where to spend the budget instead

If a modal is off the table, the question becomes what the same money buys elsewhere in the logged-in experience. Three things consistently return more than a styled login page did.

A reorder path. For any brand with repeat purchase, letting a customer reorder a previous order in one action from the account area is worth more than anything you could do to a sign-in form.

Self-serve returns. Every return handled without a support email is cost removed and a customer who feels in control. This is a natural full page target.

Anything that makes an account worth having. Store credit balances, membership status, saved preferences, order tracking that does not require an email. Customers sign in when there is a reason to, and the reason lives in the account area rather than at the door.

The modal was optimising the moment of entry. The retention actually comes from what is behind it.

Can I still have a login popup on Shopify?

Not on customer accounts with a standard theme. Sign-in happens on Shopify-hosted pages that cannot be opened in a modal or intercepted. A headless storefront using the Customer Account API gives you control of the frontend, and on Plus a custom identity provider replaces the sign-in experience.

Can I style the Shopify login page?

You can apply branding, logo, colours and typography, so it matches your store. You cannot restructure the page or apply arbitrary CSS. Configure the branding settings properly before concluding the pages look generic, since many stores never do.

What can customer account UI extensions actually do?

They add functionality inside the account area at block, full page or static targets, can read metafields across eight resource types, and can call external services once network access is approved. They cannot alter the sign-in flow itself, and they run in a Web Worker without DOM access.

Why is my extension failing to deploy?

Most often the 64 KB compiled bundle limit. It is enforced at deployment, so a bundle that grew past it with a new dependency will simply stop deploying. Check bundle size before assuming the problem is your code.

Is it worth going headless just for the login experience?

Almost never on its own. Headless is a large commitment covering your entire storefront, and login styling is a small part of it. It becomes reasonable when you have several reasons, such as performance requirements, a custom frontend team, and content needs that Liquid handles badly.

Talk to us about your account experience

Free review. Email hello@exactwhy.com with subject "Account experience" and your store URL plus what the old login did that you miss. We respond within 4 hours telling you what is recoverable with branding and extensions, and what genuinely is not. Often more is recoverable than people expect once they see full page targets.

Paid work, Rs 40,000 to Rs 1.5 lakh. Branding configuration, rebuilding lost account functionality as UI extensions within the real constraints, and testing across the sign-in paths.

Ongoing Shopify development, Rs 20,000 to Rs 50,000 a month. For brands where the logged-in experience is part of how they retain customers.

The honest summary is that you traded control of the login page for a sign-in flow you no longer have to maintain. Whether that is a fair trade depends entirely on what you build in the account area now, which is where the remaining control actually lives.