Checkout UI Extensions: Three Per Target, 64 KB, No Exceptions

Every checkout customisation project on Shopify Plus runs into the same two limits, and both are hard. A merchant can add up to three checkout UI extensions to the same block target, and each extension's compiled bundle cannot exceed 64 KB. There is no setting to raise either number, and no support ticket that moves them.

That changes how a project is scoped. Four ideas for the same target is not a build plan, it is a triage problem. The team has to decide which three earn a slot and which one goes elsewhere, or gets cut. Most build estimates that blow up do so because nobody checked the limits before promising the fourth idea.

The two numbers that shape every build

A target is a placement in the checkout flow: a block in the information step, the shipping step, the payment step, or the thank-you page. Each target holds three extensions. A banner, a custom field, and an upsell can share a target. A fourth banner cannot, even if it is small.

The thank-you and order status targets play by slightly different rules: they can read metafields but they cannot write them. That matters for any idea that needs to record something at the moment of purchase. Read the target list before designing the flow, not after the design is approved.

What counts as a target

Extensions run in an isolated sandbox with a restricted API. There is no direct DOM access, no jQuery, and no dropping a third-party script tag wherever you like. Calling an outside server needs the network access capability, and every external call adds latency to the page where shoppers decide to pay.

Extensions that make excessive changes are rate limited for the rest of the buyer session. Batch updates together instead of firing them one at a time. A chatty extension that updates on every keystroke will get throttled mid-checkout, and the shopper will see a field that stops responding for no visible reason.

The sandbox rules that surprise teams

UI extensions change what the shopper sees. Shopify Functions change what the checkout does: discounts, delivery options, payment options, and cart validation, all server side. If the idea is a rule rather than a display, it belongs in a Function, not in an extension slot.

Keep reading: Checkout Functions vs UI extensions: which one owns the discount, Checkout branding API: the tokens worth setting first.

When to use a Function instead

That distinction is the way out of the three-per-target limit. A discount rule does not need a UI extension at all. Neither does a delivery rule or a payment rule. The extensions are for the three things the shopper should see, and the Functions are for everything the checkout should do. Spend the slots on the visible work.

Frequently asked questions

How many checkout UI extensions can share one target?

Up to three per block target, and each compiled bundle is capped at 64 KB. A fourth idea for the same target has to go elsewhere or get cut.

Can checkout UI extensions access the DOM?

No. They run in an isolated sandbox with a restricted API, no direct DOM access, and no arbitrary JavaScript. Calls to outside servers need the network access capability.

What is the difference between a UI extension and a Function?

A UI extension changes what the shopper sees: banners, fields, upsells. A Function changes what checkout does: discounts, delivery options, payment options, and cart validation, all server side.

Can thank-you page extensions write metafields?

No. Thank-you page targets can read metafields but cannot write them. Any idea that needs to record something at purchase has to do it another way.