All Collections
Using the Mutiny Experience Editor
How Mutiny works with dynamic class names
How Mutiny works with dynamic class names

What to expect when personalizing elements with dynamic class names.

Updated over a week ago

Note: the features described below are currently in beta. Please contact your dedicated Growth Strategist for more information.

Dynamic class names are increasing in popularity across the web. Here, we'll talk about what they are, and how Mutiny handles them.

What are dynamic class names?

Element class names are attributes tied to an element that helps you identify it. You can use class names to apply styles, custom javascript, or in Mutiny's case, identify which elements should be personalized based on a certain experiment. Here's an example:

<button class="blue">Click Me!</button>

In this example, the <button> element has a class name of blue. You may then choose to style that class to set the background-color to blue:

.blue {

Dynamic class names use this same concept, but rather than the class name being blue, you'd more likely see something like daVUaS. This is a random string of characters that are generated automatically by CSS-in-JS libraries. Whats more, is that these class names may not stay the same. Depending on what edits you make to your site, the element with class daVUaS may later turn into jdTncd.

How do dynamic classes affect Mutiny?

Mutiny uses class names in a few different ways. Most importantly though, we use it to target elements that you want to personalize. For example, assuming thats the only button on the page with the class name of blue, Mutiny may target that element using that class name. So, if you changed the color of that button to red using Mutiny's editor, when Mutiny loads on your site, it'll say "give me the button with the class name of blue, and change its background-color to red." Even if you're making other changes, like changing the button text, Mutiny may still target that element using the class name of blue.

If your site was using dynamic class names, Mutiny would save the experience knowing that that blue button had a class name of daVUaS. If that class name changed later on to jdTncd, Mutiny wouldn't know the new class name, and thus wouldn't personalize that element, which would result in unexpected things showing on your site.

How does Mutiny solve this problem?

The first problem to solve is knowing which elements have dynamic class names. Sometimes a random string of characters will look like a dynamic class name, but its actually a static string of random characters. In order to identify dynamic class names, Mutiny needs to understand the specific library being used to generate these class names. These libraries have different ways of exposing their dynamic classes, so they have to be supported individually. Right now, we current support these libraries, and we'll continue to update this list as more libraries are supported. If you're using a CSS-in-JS library that isn't on this list, let us know!

We also allow you to add in a specific data attribute to manually indicate that certain stylesheets or elements should be ignored by Mutiny. To do this, add on the attribute data-mutiny-ignore-styles to any element, <style> or <link>.


<link rel="stylesheet" href="" data-mutiny-ignore-styles>
<style data-mutiny-ignore-styles> ... </style>

Once we've identified the dynamic class names on the page, we need to do some work to ensure that even if that class name changes, we will continue personalizing it correctly. To do this, we have the option to "inline" your styles. If you click on an element where we've detected dynamic class names, the editor will show a button giving you this option:

When you click this button, you'll see that the HTML changes a bit:

Mutiny has done two things here:

  1. We've updated the element to have static class names. in the image above, these are mutiny-style-daVUSaS and mutiny-style-ciedhj. We're using the original dynamic classes that may have existed, but these will now exist on the element indefinitely, even if that original dynamic class changes.

  2. We're adding a <style> sheet to the HTML. This style sheet is copying any styles that currently exist on the element and applying them inline. This will ensure that these styles persist even if the dynamic class name changes.

In addition to inlining styles, the Mutiny editor will ensure that any element using a dynamic class won't be part of the selector we choose to target that class.


Its important to note that there are some inherit risks to using this method. The biggest risk is that once Mutiny applies this inline style, any changes that are made to the website outside of Mutiny won't apply when this personalization loads on the page. In some ways, this is desirable as your personalization will still persist, but you nonetheless run the risk of encountering unexpected behavior on your site.

Its also important to note that Mutiny does impose a 50mb limit on changes made in the content box in the editor, and these inline styles will count towards that limit. We impose this limit to ensure that Mutiny is able to load quickly without jeopardizing site speed. To help mitigate this risk, we recommend making content changes as specifically as possible. For example, if you want to edit the <h1> on your site, make the edit on or as close to the <h1> element as possible.

Did this answer your question?