Shopify Deletes Custom Checkout Fields on August 26 — 'Just Build a Checkout Extension' Doesn't Work Below Plus

By Milan Dhameliya · 2026-08-04 · 7 min read

Every non-Plus Shopify store loses checkout.liquid and the Additional Scripts box on August 26, 2026, taking any custom checkout field with it. Checkout UI Extensions are the advertised fix, but the extension points that render inside the actual checkout steps are Plus-only. Here's the field-collection method that survives the deadline on every plan.

If your checkout has a gift message box, an engraving field, an installation date picker, or a "buzzer code for delivery" text input, and you built it by injecting Liquid or JavaScript into checkout.liquid or the Additional Scripts box, mark August 26, 2026 on your calendar. That is when Shopify finishes the checkout extensibility migration for every plan below Plus — Basic, Shopify, and Advanced — and automatically strips out whatever legacy checkout code is still running. The field does not get migrated for you. It just stops rendering.

The frustrating part is not the deadline. It is the advice that shows up when you search for a fix. Almost every tutorial says to rebuild the field as a Checkout UI Extension. That is correct for a Shopify Plus store. It is not an option for anyone else, and the reason why rarely makes it into the first paragraph.

What actually happens on August 26

checkout.liquid was already deprecated for the core Information, Shipping, and Payment steps back in August 2024, and the Thank You and Order Status pages followed for Plus stores in 2025. August 26, 2026 is the enforcement date for every remaining plan. After it passes, Shopify removes legacy checkout customizations automatically and moves the store onto the standard checkout configuration. Any JavaScript sitting in Settings > Checkout > Additional Scripts stops firing on that date, full stop — no grace period, no warning banner on the storefront, no error in the order.

If a custom field lived in that script box — rendered on page load, validated on submit, and written into the order note — it disappears the same way the tracking pixels in the Additional Scripts box disappear and the way custom discount logic in the old Script Editor already has. Same deadline, same underlying cause, different casualty.

Why "build a Checkout UI Extension" is the wrong answer for most stores reading this

Checkout UI Extensions are Shopify's real, supported replacement for checkout.liquid customization — but the extension targets that render inside the actual checkout steps (purchase.checkout.*, the ones that can add a field to the Information, Shipping, or Payment step) are gated to Shopify Plus. A store on Basic, Shopify, or Advanced cannot install or run one there, regardless of which app claims to offer it. The only checkout-adjacent extension points open to every plan are on the Thank You and Order Status pages — useful for showing a message after the order is placed, not for collecting new information before it.

This is exactly the gap a merchant ran into on the Shopify community forum: after checkout.liquid stopped rendering their custom fields, they asked how to display them again and were told to use Checkout UI Extensions with the attributes API — advice that assumes a plan they were not on. Their own read on it was blunt: it is no longer possible to modify the checkout page from the theme at all below Plus, full stop. That is the accurate summary. There is no native, first-party way to add a validated field to the checkout steps themselves on a non-Plus store, before or after August 26. The deadline does not create that limitation — it just removes the workaround (checkout.liquid) that had been quietly covering for it.

The three "custom field" mechanisms you're probably conflating

Before deciding what to rebuild, it's worth being precise about which of Shopify's three native data-collection mechanisms you actually used, because only one of them survives the deadline untouched:

• Order notes — a single free-text box for the whole order. Native, still present, but it's one field, not a labelled custom one, and you can't make it required.
• Cart attributes — arbitrary key-value pairs set with a form field named attributes[Your Key], almost always placed on the /cart page. These still get created and still attach to the order. What broke is displaying, editing, or requiring them at the checkout step itself — that rendering was the part checkout.liquid was doing, and it's gone. They also have a long-standing separate gap: a buyer who checks out through an accelerated button (Shop Pay, Google Pay, Apple Pay) straight from the product page never visits /cart, so an attribute field that only exists on the cart page never gets filled in. Merchants have been reporting that exact symptom for years, independent of this deadline.
• Line item properties — key-value pairs attached to one specific cart line, set with a field named properties[Your Key] inside the product's Add to Cart form. These are unrelated to checkout.liquid, unrelated to Additional Scripts, and untouched by the August 26 deadline. Shopify renders them under the line item in cart, checkout, the order confirmation, and the admin order page automatically, with no extension and no app required.

If your custom field was a cart-page attribute rendered into checkout by a script, it breaks. If it becomes a line item property collected on the product page instead, it survives — on every plan, permanently, for free.

Migrating a field to a line item property

Move the input into the product form itself — the one that already submits to /cart/add — rather than the cart or checkout page. In most themes that's sections/main-product.liquid or the product template's form block:

<div class="product-form__custom-field">
  <label for="Properties-GiftMessage">Gift message (optional)</label>
  <textarea
    id="Properties-GiftMessage"
    name="properties[Gift Message]"
    maxlength="200"
  ></textarea>
</div>

<div class="product-form__custom-field">
  <label for="Properties-Engraving">Engraving text (required)</label>
  <input
    type="text"
    id="Properties-Engraving"
    name="properties[Engraving]"
    maxlength="30"
    required
  />
</div>

Both inputs must sit inside the existing <form> that posts to /cart/add — that's what turns them into line item properties instead of just inert page content. Because the property is captured in the same request that adds the item to the cart, it travels with the line item from that point on, including through an accelerated checkout button, since there's no separate cart-page step for the buyer to skip.

For a field that must be filled in but isn't a native HTML required attribute the theme's Add to Cart handler already respects, validate it explicitly before the request fires:

const form = document.querySelector('form[action^="/cart/add"]');

form?.addEventListener("submit", (event) => {
  const engraving = form.querySelector('[name="properties[Engraving]"]');
  if (engraving && !engraving.value.trim()) {
    event.preventDefault();
    engraving.reportValidity();
  }
});

Two details worth knowing before you roll this out:

• Prefix a property's key with an underscore — properties[_Internal SKU Note] — and Shopify hides it from the customer-facing cart, checkout, and order confirmation while still showing it on the admin order page. Useful for routing or fulfilment notes you don't want the buyer to see, without needing a metafield.
• Line item properties are per line item, not per order. A gift message needs to be re-entered for each product that should carry one — that's a real behaviour change from a single order-level note box, and worth flagging to whoever owns the fulfilment process before launch, not after the first complaint.

What genuinely has no replacement below Plus

Be honest with whoever's asking for this back: if the field's whole point was appearing at the checkout step — a tax ID prompt on the Payment step, a delivery-date picker that only makes sense once shipping is confirmed, anything conditional on checkout-only state — moving it earlier to the product or cart page changes the buyer's flow, and for some use cases that's a real regression, not a cosmetic one. There is no first-party way to render a new, validated field inside the Information, Shipping, or Payment step on a non-Plus store, on August 26 or afterward. Apps advertising "custom checkout fields" for non-Plus stores are, mechanically, front-loading collection to the cart or product page the same way described above — not a workaround Shopify itself doesn't also have. If the field truly has to live at the checkout step, the honest options are moving to Plus or accepting the field earlier in the funnel; there isn't a third path.

Audit checklist before August 26

1. Open Settings > Checkout > Additional Scripts and copy out every field, script, and validation rule currently living there before it stops firing.
2. Search your theme for any Liquid or JS still referencing checkout.liquid, attributes[, or a checkout-step DOM hook, and separate genuine checkout-step fields from ones that were only ever rendered on the cart page.
3. For each field, decide: does it truly need to appear at the checkout step, or can it move to the product/cart form as a line item property? Most gift messages, engravings, and delivery instructions can move without changing what the buyer experiences in any meaningful way.
4. Rebuild the movable ones as line item properties, test through both a normal checkout and an accelerated (Shop Pay/Google Pay) checkout, and confirm the value shows up on the admin order page.
5. For anything that can't move, decide now — not on August 26 — whether that's a Plus conversation or a feature you're retiring.

This is the same underlying deadline behind the Shopify Scripts shutdown and the Additional Scripts tracking migration — checkout.liquid is being switched off piece by piece, and each piece needs its own audit rather than one blanket fix. If you want a hand auditing what your checkout actually depends on before August 26, or deciding which custom fields are worth moving versus retiring, get in touch, or see what I do for Shopify stores working through checkout extensibility migrations.