Metafield values limited to 16KB

Changelog
41

Yes even when using 2026-04 or future API versions. Essentially if your app uses a JSON metafield today, you will be grandfathered on all future versions

42

Thanks an lot for making it 128kb at least instead of 16kb.

However, you mentioned that existing JSON users will be grandfathered in with a 2MB limit. That sounds like it could create an unfair advantage. It’s not an issue for me personally, since mine would qualify for 2MB, but I’m not sure how new developers will feel about that.

I also saw that developers can apply for a limit increase after April 1st. Could you clarify how that process works? If a request is approved, what would the new limit be? Would it be capped at 2MB, set below 2MB, or could it potentially exceed 2MB?

43

I did a little response on X, but so I can type more here….

I do not THINK I would hit the 128KB with how I work. However, I am always a bit worried about my weight so to speak. I do not know how to effectively test the weight of my existing JSON, let alone new incoming JSON. Any metafield for that matter. At this time honestly, I just save my JSON as compressed as possible to a .json file and use that as a guess.

Is there a big LoE to somehow have a new field on the Metaobject object that would tell the developer the current data weight / size of the metafield value? For new incoming metafield values I don’t think anything on the Shopify side could even be done to check the incoming value weight unless there was some metafieldPrepareSet mutation or something that would return the expected weight… We know an error would return trying to push a large value in but I want to try to be as protective as possible to make sure things go smoothly.

I am not always developing in an environment where I am in total control to check data sizes before and after send such as my own app. Sometimes I may just have to right what I can in Flow depending on the client I may work with.

44

Appreciate your empathy for newer devs! However, we don’t expect this will create an unfair advantage for existing apps. Our discussions with the community highlighted 128KB covers most use cases. Based on our data we expect most devs should be able to build whatever they need within those constraints, so the intake process is more like an escape valve for the exceptional use cases where 128KB won’t work.

The other frustration we heard consistently was the effort required to refactor existing apps to fit within 128KB. We’re therefore grandfathering apps (with the caveat that we’ll be reaching out individually to the devs who are approaching our storefront performance trip wires so we can work with them on solutions).

Re the intake process: Requests will be reviewed by the team. The hurdle will be to prove that you have a unique use case that cannot be modelled efficiently within 128KB AND your use case won’t impact storefront performance. Those who do get approved would receive an increased limit up to a max of 2MB.

45

So with 2026-04, we’re updating the validation message to tell you the size of your write on error. But the idea of a valueByteSize field on success is interesting as well. Will take that to the team and get back to you; I see no reason not to if we can do so efficiently.

In the interim, it’s quite simple to check the size of the retrieved value on your end before writes:

// result is the parsed JSON response from your GraphQL call
const value = result.data.metaobject.body.value; // this is the string

// Get byte length in UTF-8
const encoder = new TextEncoder();
const bytes = encoder.encode(value);
const byteLength = bytes.length;

console.log('String:', value);
console.log('Byte length:', byteLength);

I get that this might not be available to you in environments you don’t control though. I do still think you should be able to do this in Flow, but will have to check when I have some time in between meetings. Will follow up later today.

47

@Darius-Shopify I wanted to know if if we can use MetaObject as a work around the metafield limit, we’re considering migrating our app’s JSON config from metafields to metaobjects with a json field type.

I ask support and looked at Shopify’s documentation, I don’t see where it explicitly state whether Metaobject JSON fields have the same 128KB limit that applies to standalone SON metafields.

limit makes it complex to manage data across multiple metafields / metaobjects. We’ve learned that 128KB is a more reasonable limit

However, looking at the post you mentioned “metaobjects”. I wanted to confirm if this was the case, where metaobject is not included in the limits.

48

@btrain137 the limit applies to the metaobject as well.

49

Hi @Darius-Shopify just looking to clarify the grandfathering mechanism here:

Therefore, we’re grandfathering all existing apps who use JSON metafields prior to April 1st, 2026 at the current 2MB JSON limit.

What does exactly qualify an app for this grandfathering?

  • Must it be an app already in the App Store? What about custom apps? Or apps with Public distribution but still in the development process? Or apps ready to launch but still in the review process?
  • What does “use JSON metafields mean”? Apps that have defined a JSON metafield in any store in their lifetime? including a dev stores? Or only apps that have defined JSON app-metafields in their .toml config?
  • How can we make sure our apps are being grandfathered prior to April 1st 2026? Is there a set of deterministic objectives you can share, or a communication channel we can use to check on a per-app basis about this?
  • Will the grandfathering apply for existing JSON metafields and new ones? Or only previously defined metafield definitions by the app will be grandfathered? Same question for metafields within metaobjects.

Thank you!

50

Hey @muchisx

All apps, public and custom, are eligible for grandfathering.

Any app that has created a JSON metafield definition (including as a JSON field in a metaobject) before April 1, 2026 will be grandfathered. The method of creation doesn’t matter, whether defined via the app’s TOML config or through the API, both qualify.

Grandfathering is at the app level. Once your app is grandfathered, it applies across all stores (production and dev), and to all JSON metafields going forward, both existing definitions and new ones.

To verify eligibility, the easiest way is to try writing a metafield value >128KB using the 2026-04 version with your app. If it works, that app has been grandfathered.

51

Does the grandfathering also apply to the UI extensions limit change by any chance?

I haven’t yet migrated to the preact ui-extension versions but I suspect the limit of my app’s bundle will still far exceed the 64kb limit under this new change (it’s currently sitting at ~500kb).

I think migration by splitting 1 big extension in many smaller ones would create a lot of disruption for existing merchants as the change required within each checkout profile would have to be manually done, and each extension would also have fewer features available, adding to the complexity of the migration.

Echoing concerns from others in this thread:

…Also this has not been announces (or not in the changelog or that I have seen yet). But I saw UI extensions files size are also being reduced from 2mb to 64kb. This is also another enormous change which should be discussed as well. If its an issue for metafields, its an even bigger issue for UI Extensions. That size is way too small. —Jurgen Feuchter

…P.S. - The UI extension limit from 2mb to 64kb is also going to cause a lot of issues for many of us. —Alex_Hooper

52

Hi @kyle

I’m also affected by this change and as such, I just created a new discussion so we can focus on asking for reconsideration on it!

cc @Jurgen_Feuchter @Alex_Hooper