Deep Dive into Shopify’s Global Objects in Liquid

Shopify’s Liquid templating language is a cornerstone of theme development, enabling developers to create dynamic and customizable e-commerce storefronts. Among its many features, global objects stand out as essential tools for accessing and manipulating store data. In this blog, we’ll explore Shopify global objects in Liquid, covering their use cases, properties, and practical applications.

What Are Shopify Global Objects?

Liquid uses global objects, which are predefined variables that give access to key information about a Shopify store. These objects demonstrate data structures like products, collections, customers, details in the cart, and more. They are automatically available in all Liquid files, thus being critical for building data-driven dynamic themes.

What Are Shopify Global Objects?

Liquid uses global objects, which are predefined variables that give access to key information about a Shopify store. These objects represent data structures like products, collections, customers, and cart details.

They are automatically available in all Liquid files, making them critical for building data-driven, dynamic themes.

Why Global Objects Are Good for Performance

Besides being convenient to use, global objects also carry a performance advantage: Shopify prefetches them. That means accessing their data doesn’t trigger additional database queries.

This matters most when compared to the alternative. Getting product or cart information through a custom API route from JavaScript requires extra requests and responses to load the data. Using the global objects is much faster and more efficient.

This is why many experienced Shopify developers recommend using global objects whenever possible, instead of fetching information via API requests.

A Few Objects Worth Knowing About in Addition to the Basics

The objects described above are the ones developers use most often. A few others are worth mentioning too.

all_products provides direct access to any product in the store via its handle, even outside that product’s own template. It’s useful for showcasing a particular product on an unrelated page.

linklists exposes the store’s link lists, which can be used to render custom menu markup outside Shopify’s built-in navigation system.

page is the counterpart of article for store pages, such as the About page or a custom landing page. It exposes the page’s title and content.

localization is necessary for internationalized stores targeting multiple languages and currencies. It allows the appropriate language and money formatting to be used on a page.

These objects see less use than product, cart, or customer. Still, they can provide a convenient shortcut when building a custom checkout or working with Shopify’s theming system.

The Philosophy Behind Liquid’s Global Objects

It’s useful to understand why Shopify built Liquid this way, rather than forcing theme developers to query data manually. The answer ties back to Liquid’s core philosophy.

Liquid is a restrictive, sandboxed language. It aims to provide exactly enough functionality to be useful while keeping the risk of abuse low.

Liquid templates are meant to build pages and UI elements that any Shopify merchant would recognize. Because of this, templates work with a standard set of objects containing information relevant to any shop. This makes Liquid flexible and easy to learn, without requiring a technical background.

It also explains Liquid’s tendency to abstract away the inner workings of Shopify’s database and business logic.

This design philosophy has real implications for theme development. Most of the objects that theme code queries directly are standard across all shops. That means most theme code interacts with these objects in a uniform way.

This uniformity is a major reason the wider theme development ecosystem is so productive. A complex theme built for wide use typically relies on commonly available objects. That dramatically lowers the barrier to entry for new theme developers.

Shopify’s design choices also reflect its priorities as a company that favors its own products and services. By abstracting away data-fetching details and standardizing (if limiting) the available objects, Shopify makes dynamic content performant.

The resulting performance benefits are shared by Shopify and by the independent developers releasing themes on its platform.

This approach can still feel limiting to theme developers. But it lets Shopify deliver consistently high performance to customers, while giving developers room to work without getting bogged down in infrastructure details.

Why Shopify’s Object Model Has Changed Over Time

Shopify’s global object system hasn’t stood still since Liquid launched. It has evolved to meet growing needs as the platform serves an increasingly diverse set of commerce customers.

Early versions of Liquid offered a limited object set: a simplified catalog of products, collections, and a cart. As Shopify’s merchant base diversified — multi-currency stores, subscriptions, wholesale and B2B catalogs, content-heavy sites — the object model expanded too.

This growth let theme developers build more specialized stores without resorting to workarounds or a wider set of third-party apps for core catalog functionality.

The introduction of metafields exemplifies this evolution. Rather than anticipating every way merchants might want to extend product data — care instructions, materials, size charts, custom badges — Shopify built a flexible system.

Merchants and developers can define their own custom fields for any object, then expose that data using the familiar global object syntax. This let Shopify avoid an ever-expanding list of business-specific fields, while still supporting increasingly specific customizations.

More recently, Shopify’s focus on localization and internationalization has driven changes too. A multi-currency, multi-language store has far more data to represent than a single shop selling in one currency and language.

The object model’s evolution reflects this reality. Technical needs from a distributed merchant base — not anticipatory design — continue to drive the platform forward.

1. Store Information

These objects contain details related to the store itself, such as its name, URL, and localization settings.

shop: Refers to the store and carries metadata such as the shop name, domain, and currency.

Example Usage:

<p>Welcome to {{ shop.name }}!</p>
<p>Your currency is set to {{ shop.currency }}</p>

settings: Retrieves theme settings that can be set in the Shopify admin under Online Store > Customize Theme.

Example Usage:

<p>Support Email: {{ settings.contact_email }}</p>

Working with Shop Settings in Practice

The settings object holds a surprising amount of power. It’s the bridge between your theme’s code and the controls exposed to merchants in their admin.

Any value defined in your theme’s settings_schema.json can be accessed as a property. A merchant changes a value in the theme editor, and it updates immediately in settings.primary_color.

This matters a lot. It means you can ship one theme with a single codebase, but brand it differently for each merchant based on their chosen settings — with no code changes required.

Themes built for the Shopify Theme Store lean on this heavily. Almost every visual customization you see in a theme’s editor is linked to a value in the settings object.

A Note About the Shop Object’s Locale Data

Beyond name and currency, the shop object holds some locale-related information that’s easy to overlook.

shop.locale gives you the code of the store’s current language. This is useful for conditionally displaying alternate content in a multi-language theme, without needing a localization app.

shop.money_format contains the money format string used to display prices in the store’s currency. It’s useful if you want a custom price display format instead of the default one the money filter provides.

These small details matter when building themes that need to account for multiple configurations — not just the one you’re testing against.

A Note about the Shop Object’s Locale Data

In addition to the name and currency, the shop object contains some locale-related information that is easy to overlook.

shop.locale will give you the code of the language that the store is currently set to, which can be useful for conditionally displaying alternate content in a theme that supports multiple languages, without the need for a localization app.

The shop.money_format property contains the money format string that is used to display prices in the store’s currency, which can be useful if you want to use a custom price display format, as opposed to the default one that the money filter provides.

These small details can make a big difference when it comes to developing themes that need to account for multiple configurations, as opposed to the one that the developer is testing.

2. Customer and User Data

These objects refer to logged-in customers and their accounts.

customer: Stores information about the currently logged-in customer, including name, email, and orders.

Example Usage:

{% if customer %}
  <p>Welcome back, {{ customer.first_name }}!</p>
{% else %}
  <p>Please log in to view your account details.</p>
{% endif %}

customer.orders: Retrieves a history of customer orders; however, this can only be accessed with templates such as the customer accounts.

3. Product and Collection Data

These objects render and manipulate dynamic product and collection data.

product: Refers to a single product, usually within the product template. It contains information such as title, price, variants, and metafields.

Example Usage:

<h1>{{ product.title }}</h1>
<p>Price: {{ product.price | money }}</p>

collection: A collection of items, usually in the collection template

Example Usage:

<h1>{{ collection.title }}</h1>
<ul>
  {% for product in collection.products %}
    <li>{{ product.title }} - {{ product.price | money }}</li>
  {% endfor %}
</ul>

Variants: The Part of product Beginners Miss

Most product-related examples focus on product.title and product.price. But real stores almost always involve variants — different sizes, colors, or configurations of the same item.

product.variants is a list of every purchasable option under that product. Each variant carries its own price, SKU, and availability, separate from the parent product.

{% for variant in product.variants %}<br>{{ variant.title }} - {{ variant.price | money }}<br>{% endfor %}

Skipping variant-level logic is a common early mistake. A product might show as “in stock” overall while the selected variant is actually sold out — confusing customers at checkout.

product.selected_or_first_available_variant helps here. It gives you the variant a customer has selected, or falls back to the first available one. That’s a more reliable choice for pricing and stock displays than the raw product fields alone.

Collections and Pagination

Looping over collection.products is fine for small collections, but it can be slow for large ones.

By default, Shopify paginates results for large collections. That means collection.products includes only the products on the current page, not the whole collection.

The paginate tag can be used to loop over all products in a collection:

{% paginate collection.products by 12 %}<br>{% for product in collection.products %}<br>{{ product.title }}<br>{% endfor %}<br>{{ paginate | default_pagination }}<br>{% endpaginate %}

4. Shopping Cart and Checkout Data

These objects help manage a customer’s cart and checkout flow.

cart: Holds the details of items in the customer’s cart, including total price and individual line items.

Example Usage:

<h2>Your Cart</h2>
{% for item in cart.items %}
  <p>{{ item.product.title }} - Quantity: {{ item.quantity }}</p>
{% endfor %}
<p>Total: {{ cart.total_price | money }}</p>

checkout: Used within the checkout template to access order summary details.

5. Blog and Article Data

These objects are helpful in handling content within the blogging feature of Shopify.

blog: Any blog within the Shopify Store.

Example Usage:

<h1>{{ blog.title }}</h1>

article: Represents any single blog post.

Example Usage:

<h2>{{ article.title }}</h2>
<p>{{ article.content }}</p>

Working with Blog Comments

Articles have a comments object when comments are turned on for the associated blog.

article.comments_count gives you the number of comments for an article. This is useful for something like “12 comments” without looping through all the comment data.

The actual comment data lives under article.comments. It contains the author, content, and date for each comment, letting you build your own comment display instead of using Shopify’s default UI.

This is a small corner of the blog objects in Liquid. Still, it comes up periodically when building content-heavy Shopify themes.

Blog Tags and Filtering

Blogs can have tags, just like products. This lets you organize content like collections, but specifically for blog posts.

blog.tags returns an array of all tags used in the blog. It’s useful for building a tag-filtered list or navigation menu.

Paired with article.tags, you can filter articles to display only those with a given tag. This pattern is common for content-heavy Shopify stores that supplement their catalog with news or editorial content.

6. URL and Routing Objects

These objects help manage URLs and route navigation.

request: Contains information about the current URL, query parameters, and HTTP method.

routes: Used to generate links for pages and resources in your store.

Example Usage:

<a href="{{ routes.cart_url }}">Go to Cart</a>
<a href="{{ routes.account_login_url }}">Log In</a>

Understanding the request Object

request is one of the less glamorous global objects, but it solves real problems.

It gives you the current page’s path, host, and query parameters — useful for building things like “you are here” breadcrumbs or conditional logic based on the current URL.

{% if request.path contains '/collections/' %}<br><p>You're browsing a collection.</p><br>{% endif %}

This kind of path-based conditional shows up often in themes that need slightly different behavior on different page types, without duplicating an entire template.

Why routes Beats Hardcoded URLs

It’s tempting to hardcode a link like /cart directly in a template. Resist that urge.

Shopify stores can have different URL structures depending on settings, locale, or app-based redirects. Hardcoded paths can quietly break under these conditions.

routes generates the correct URL dynamically, accounting for the store’s actual configuration:

<a href="{{ routes.all_products_collection_url }}">Shop All</a>

This one habit — always preferring routes over manually typed paths — avoids a whole category of broken links that only surface after a store’s settings change.

Advanced Use Cases

1. Using Metafields with Global Objects

Metafields extend global objects by adding custom fields to products, collections, and other resources.

Example Usage:

<p>Material: {{ product.metafields.custom.material }}</p>
<p>Care Instructions: {{ product.metafields.custom.care_instructions }}</p>

2. Personalizing Storefronts with customer and cart

You can create personalized shopping experiences by combining global objects like customer and cart. For example:

{% if customer %}
  <p>Hi {{ customer.first_name }}, you have {{ cart.item_count }} items in your cart.</p>
{% endif %}

3. Custom Sorting and Filtering

Apply Liquid loops and filters for more advanced sorting and filtering. For instance, sort products by price:

{% assign sorted_products = collection.products | sort: 'price' %}
{% for product in sorted_products %}
  <p>{{ product.title }} - {{ product.price | money }}</p>
{% endfor %}

Thinking About Global Objects as Part of a Larger System

It’s easy, early on, to treat each global object as an isolated lookup table — product, cart, and customer as separate tools to query whenever needed.

In practice, effective theme development means thinking about these objects as part of a larger system. The theme as a whole represents a customer’s coherent shopping experience.

The focus shifts from “what properties does this object have” to “how do these objects interact during a typical customer journey.” A shopper browses a collection, adds an item to their cart, then heads to checkout — a journey through several distinct states.

A theme that correctly reflects the shopper’s current state at each step — what’s in the cart, whether they’re signed in, what inventory is available — feels far more polished and trustworthy than one that ignores these connections.

This systems-level thinking matters even more once a theme moves beyond a simple, vanilla setup. Merchants often request features that combine several objects in non-obvious ways.

Personalized recommendations based on cart contents, or alternate messaging depending on whether a cart item is also on a customer’s wishlist, are common examples. Developers who understand the relationships between Liquid objects tend to implement these features far more easily than those who treat each request as an isolated task.

Liquid’s design philosophy favors a set of simple objects that combine into more complex behavior, rather than a large catalog of narrow, single-purpose ones.

Why Documentation Alone Isn’t Enough

Shopify’s official documentation for global objects is comprehensive. It covers the vast majority of properties and use cases developers need.

That said, documentation only gets you so far. It describes what can be done with an object, but less often what should be done in a given context, or how to approach it.

Knowing that product.available is a property is different from understanding the many places in a theme that need availability checks: quick-add buttons on a collection list, variant selectors on a product page, line items in a cart where a product has sold out.

This is why studying well-built Shopify themes tends to teach you faster than documentation alone. Watching how experienced developers group and combine objects — and where they avoid common pitfalls — reveals conventions that rarely make it into written docs.

Documentation typically covers a single object and its properties. It rarely captures the usage patterns that emerge from working across dozens of objects and templates in one cohesive theme.

Security Considerations When Using Global Objects

Global objects are convenient, but they render directly into your storefront’s HTML. That means anything unsanitized carries real risk.

Customer-provided data — a name, a review, a search term — should be treated with the same caution you’d apply anywhere user input touches your output.

Liquid’s escape filter helps here. It converts special characters into safe HTML entities, preventing malicious input from being interpreted as code.

{{ customer.first_name | escape }}

This matters most where customers can directly influence output, like search results or comment sections. It matters less in places pulling only from data you control, like your own product catalog.

Object Availability Across Template Types

Not all objects are available in all templates. This isn’t always obvious, and it can trip up new developers.

For example, product is only available in product templates, and collection only in collection templates. Accessing product on your homepage won’t throw an error — it will simply return blank.

This is by design, not a bug. Liquid won’t error on unavailable objects; it just returns nothing.

Always check Shopify’s documentation for which templates a given object supports. Verify availability before accessing nested fields or properties. A simple {% if product %} check before outputting product-related content is always a good idea.

Tips for Working with Global Objects

1. Use the Shopify documentation. It provides comprehensive details about each global object.
2. Combine objects. Many powerful use cases come from combining objects like cart and product.
3. Test in the theme editor. Use Shopify’s preview mode to test your code in real time.
4. Minimize loops. Excessive looping can slow down your theme — use filters and pagination where possible.

Common Pitfalls

• Accessing unavailable data. Some objects (e.g., cart) aren’t available on every template. Check availability first.
• Overloading Liquid with logic. Liquid was built for templating, not complex logic. Offload heavy calculations to JavaScript when needed.
• Misusing filters. Filters are powerful but can introduce bugs if misapplied. Chaining too many filters can produce unexpected results.

Object Availability at a Glance

Conclusion

Shopify global objects are flexible and essential for building dynamic, engaging storefronts. Whether you’re showing product information, personalizing customer experiences, or customizing navigation, they’re the foundation of effective theme development.

Mastering and understanding the subtleties of global objects will unlock the full potential of Liquid. Deliver exceptional e-commerce experiences for all of your Shopify clients.
To learn more about Shopify and its capabilities, check out shopify’s official website.