HubL (HubSpot Markup Language) is the templating language used by the HubSpot CMS to render dynamic content. Just as Shopify uses Liquid, WordPress uses PHP, and Drupal uses Twig, HubSpot uses HubL. If you’ve worked with Django’s Jinja templating language HubL may look familiar, and for good reason.
In the beginning the HubSpot team originally built the HubSpot CMS in Python using the Jinja templating language. When they later rewrote parts of the system in Java, they needed a Java version of the same templating engine so existing customer templates wouldn’t break. The closest thing they found was a project called jangod, an old Django templating implementation, but it didn’t fully match what HubSpot needed. So they took it, improved it, and created Jinjava.
Jinjava is a Java template engine that works like Jinja and can render templates the way their system expects. They also made it easy to plug in custom tags, filters, tests, and functions so developers can extend it. Today it serves as the core rendering engine behind HubSpot’s templating system and is available as the open-source Jinjava project.
At its core, templating is the process of combining variable data with a static layout to produce dynamic content. A templating engine (like Jinjava) does the actual work of rendering, while the templating language (like HubL) defines the placeholders and logic the engine understands. This rendering process allows developers to create reusable components, generate data-driven content, and dynamically alter presentation all on the server-side. To understand where templating fits, it helps to distinguish between server-side and client-side responsibilities.
The server-side is everything that happens behind the scenes beyond the user's view. Payment processing, form validation, user authentication, and of course dynamic page generation are all processes run remotely (on a server) rather than in the user's browser.
The client-side is everything the user sees, from fancy animations to the text content, it makes up the user interface and the user's experience. Languages that operate directly in the browser include HTML, CSS, and JavaScript, along with the many frameworks and libraries built on top of them.
HubL operates entirely on the server, generating the final HTML before the page is ever sent to the browser.
HubL's job in the HubSpot CMS is to assemble content, not to run applications. It sits between HubSpot’s data sources and the final HTML sent to the browser, deciding what to render and when, based on the data available to the page.
Because of this role, HubL has access to a specific set of CMS-managed data and nothing outside of it.
HubL can read data that already exists inside the HubSpot portal, rendering it but not modifying it. Any updates to content, settings, or CRM data must happen through HubSpot’s UI, workflows, or APIs not within templates themselves. In other words, templates decide how content appears, while HubSpot controls what the content is.
HubSpot-managed data that HubL can access includes:
Brand assets, language and locale settings, domain information, visitor state (such as membership login status), and other data derived from the HubSpot portal itself.
Metadata such as page titles and meta descriptions, select request information (URLs, cookies), publishing status, authors, subscription and membership links, required and optional template includes, and more. Some data is only available in specific environments (pages, blogs, or emails).
Tables, rows, columns, and all structured data stored within them.
Contacts, companies, products, deals, invoices, and other default or custom CRM objects. For privacy and security reasons, access to some records may be limited to authenticated or password-protected pages.
While HubL is intentionally constrained, it still provides a useful set of logic for shaping how content is rendered. Templates can evaluate conditions, loop over collections of data, reuse markup through macros, and format values using filters. These tools make it possible to build flexible layouts and data-driven pages without relying on custom backend code.
HubL cannot access server files nor perform operations outside of rendering page content. This can feel limiting to developers coming from CMSs like WordPress or from building fully custom websites. However, these limitations are for good reason.
These constraints don’t remove capabilities from the platform; they ensure functionality is implemented in the appropriate layer and help protect the stability, performance, and security of the shared CMS ecosystem HubSpot hosts.
Jinja is a general-purpose templating engine for Python, most commonly used with Django and other application frameworks. HubL is built on top of Jinja’s core syntax, which is why the two look so similar. However, Jinja is designed for trusted, self-hosted environments and allows more expressive logic, while HubL intentionally restricts that syntax to fit the needs of a managed CMS.
As another CMS in a shared hosting environment, Shopify’s Liquid has constraints similar to HubL. Where they differ is in data handling. Liquid provides fewer mechanisms for advanced data manipulation, such as reusable logic or working with complex, structured datasets.
Technically, PHP isn’t a templating language but a general-purpose scripting language. That flexibility allows users to extend their sites in powerful ways, but it also means they must actively manage security, performance, and stability themselves.
Twig is a general purpose template engine for PHP used in content management systems like Drupal and Symfony. It's syntax actually originates from Jinja and Django templating and is therefore very similar to HubL in structure but it offers more extensibility since its meant for self-hosted environments and application development.
If you’ve worked with templating languages like Liquid, Twig, or Jinja, much of HubL will feel immediately familiar. The core syntax translates well across these systems, making the ramp-up largely about learning HubSpot’s conventions rather than an entirely new language.
The bigger adjustment comes from developers used to self-hosted environments or full scripting languages. In those cases, the learning curve isn’t syntax but scope: understanding where logic belongs, adapting to read-only data access, and working within the boundaries of a managed CMS.
Beyond that, learning HubL primarily means becoming familiar with HubSpot-specific functions, variables, and data models rather than relearning templating fundamentals.