A tool for obfuscating Tailwindcss classes

[sonofmagic]

Preface

tailwindcss is an atomic class-first css framework that is very popular nowadays. Its semantic class names enable front-end developers to intuitively write and maintain styles for elements.

This intuitiveness, however, can sometimes be a bit of a nuisance. Sometimes we don't want users or outside developers to be able to visually observe the style of all elements.

For example, we visit https://tailwindcss.com , then open the developer tools and inspect the elements. Instantly, the layout and style of all those elements on the page can be guessed without even looking at the style panel on the right.

So, for the sake of making it impossible for others to visualize the style of an element in a production environment, we need to obfuscate the atomic classes generated by tailwindcss.

Solution search

When I first looked for a solution on the web, I found mangle-css-class-webpack-plugin, a webpack plugin designed to compress and obfuscate class names in html,js,css.

However, I had trouble trying to use it to obfuscate class names in tailwindcss, at first I couldn't pass in classNameRegExp and other parameters accurately, which led to my webpack build results being either completely wrong or not at all as expected, then I found a issue#10 that seemed to solve the problem. which seemed to solve the problem, but was extremely unmaintainable.

In addition, directly through the regular to modify the js literal amount of the way, it is easy to cause a small range of misunderstanding, resulting in the whole project does not run up to report errors.

So I started to think if there is any way to precisely obfuscate the class name of tailwindcss, and here is my solution.

How to implement obfuscation

First of all, in order to be more precise with the matching, I decided to implement it from the following point of view

1. to find exactly how many classes are generated by tailwindcss, I need to get the context of tailwindcss at runtime.
2. abandon regular matching and use AST across the board, i.e. use prase5 to parse and transform html, babel to parse and transform js, and postcss to parse and transform css.

To achieve the first point, I designed and wrote an npm package: tailwindcss-patch to get all the generated class collections.

To achieve the second point, I wrote a unplugin plugin: unplugin-tailwindcss-mangle, which is a webpack/ vite plugin that modifies html, js, and css to obfuscate all class names during packaging.

How to use them

So how do you use them? It's as simple as the following steps.

1. Install these 2 packages

<npm|yarn|pnpm> i -D unplugin-tailwindcss-mangle tailwindcss-patch

2. Execute the script

npx tw-patch

3. Add the prepare script to your package.json

  "scripts": {
    "prepare": "tw-patch"
  }

4. Register this plugin

Here is an example of webpack and vite

webpack

// esm
import { webpackPlugin as utwm } from 'unplugin-tailwindcss-mangle'
// or cjs
const { webpackPlugin: utwm } = require('unplugin-tailwindcss-mangle')
// use this webpack plugin
// for example next.config.js
/* @type {import('next').NextConfig} */
const nextConfig = {
  reactStrictMode: true.
  webpack: (config) => {
    config.plugins.push(utwm())
    return config
  }
}

module.exports = nextConfig

Here I use nextjs as an example, but of course vue.config.js is similar, register utwm() into webpack and then package the build and preview it to see the effect.

vite

// for example: vue vite project
import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'
import { vitePlugin as utwm } from 'unplugin-tailwindcss-mangle'
// https://vitejs.dev/config/
export default defineConfig({
  plugins: [vue(), utwm()]
})

Then execute the script:

# generate bundle
<npm|yarn|pnpm> run build
# preview
<npm|yarn|pnpm> run preview

Effect Preview

<!-- before -->
<div class="z-10 w-full max-w-5xl items-center justify-between font-mono text-sm lg:flex"></div>
<!-- after -->
<div class="tw-g tw-h tw-i tw-d tw-e tw-j tw-k tw-l"></div>

Of course, you can also customize the generated class name, check documentation for more configuration options.

Errors and feedback

If you encounter any problems or questions during use, or want to communicate, feel free to raise issue with me.

Thanks.

[maietta]

[sonofmagic]

tw-patch is a open-source tool for exposing tailwindcss context at runtime.
Source Code
otherwise, we are not able to get utility class generated by tailwindcss.

I wouldn't be patching it if I didn't find another way...

[sonofmagic]

I have been struggling with how to get the tailwindcss context in the webpack plugin.
After I learned the code and behavior of ts-patch I was inspired to implement tailwindcss-patch.
The behavior of tailwindcss-patch is just to add a few lines to the tailwindcss source code to expose the context. If tailwindcss has a way to directly obtain the runtime context in the future, then this package is naturally unnecessary.

Refers:
https://www.npmjs.com/package/ts-patch

[Jaydeep189]

Not Working

I am using Astro, which is on Vite

It is not working, I have followed the steps you mentioned

vite config

import { defineConfig } from 'astro/config';
import tailwind from "@astrojs/tailwind";
import preload from 'astro-preload';
import svelte from "@astrojs/svelte";
import { vitePlugin as utwm } from 'unplugin-tailwindcss-mangle'

import sitemap from "@astrojs/sitemap";


// https://astro.build/config
export default defineConfig({
  site: 'https://speedy-assignment.com/',
  integrations: [preload(), tailwind(), svelte(), utwm(), sitemap()];

package.json

{
  "name": "speedy-assignment",
  "type": "module",
  "version": "0.0.1",
  "scripts": {
    "dev": "astro dev",
    "start": "astro dev",
    "build": "astro build",
    "prepare": "tw-patch",
    "preview": "astro preview",
    "astro": "astro"
  },
  "dependencies": {
    "@astrojs/sitemap": "^2.0.1",
    "@astrojs/svelte": "^3.1.0",
    "@astrojs/tailwind": "^4.0.0",
    "@ernane/svelte-star-rating": "^1.1.3",
    "@splidejs/svelte-splide": "^0.2.9",
    "astro": "^2.9.6",
    "astro-preload": "^1.1.2",
    "postcss": "^8.4.27",
    "postcss-obfuscator": "^1.6.0",
    "svelte": "^4.1.1",
    "tailwindcss": "^3.3.3"
  },
  "devDependencies": {
    "@iconify/svelte": "^3.1.4",
    "astro-icon": "^0.8.1",
    "tailwindcss-patch": "^1.2.7",
    "unplugin-tailwindcss-mangle": "^1.2.7"
  }
}

[sonofmagic]

Yes, there are some issues with SSR apps right now, and it's only working on SPA apps at the moment.

[Jaydeep189]

Are there any workarounds for this using SSR?

[clarkhacks]

I'm currently using the same setup and find this interesting. Following.

[sonofmagic]

Version 2.0 will be released soon, which will fix issues in SSR scenarios.

[mohdlatif]

I am using Astro SSR and I could not make it work.. The classes never changes.

[cgxxv]

@sonofmagic This is maybe not a good solution. I think the best solution is maybe like classnames. This package works well for custom css (not tailwindcss), because it could generate this, eg: tw-eb1ac3dxd. Like this.

<!-- before -->
<div class="z-10 w-full max-w-5xl items-center justify-between font-mono text-sm lg:flex"></div>
<!-- after -->
<div class="tw-eb1ac3dxd"></div>

This solution may need a lot of work. And actually I can't find a solution for converting tailwindcss to the hashed style class.

[francoism90]

@cgxxv Did you ever found a solution?

[sovetski]

This kind of tools should be implemented by default on Tailwind in my opinion, maybe in v4?

[kissu]

There is no point in obfuscation so no, I hope it will not be part of the official package.
Total waste of time and energy.

[Khaledinges]

When performance does not matter, totally agree Otherwise very important !

[kissu]

Nah, still shit IMO. Don't see the point at all.
Web is free mostly, let's not put paywalls and shit on everything come on! 🤷🏻‍♂️

[Strangersknowme]

@kissu Yes I agree that obfuscating is not necessary. But this type of package clearly has a use case when you are building some portable components which can drop into any existing codebase. I am personally facing this problem with my project. Tailwindcss classes are clashing with the existing classes of the codebase.

A real world example would be something like a feature button or support bot or something being added to an ecom store, it is very likely that the store uses some classnames which are exact same as tailwindcss classes but defined completely differently so it is going to mess up the page's layout. I have faced this. This solution is incomplete that the OP has proposed since it only changes the classnames without copying over the functionality of the tailwind classes defeating the entire purpose of the tailwind classes. Atleast this package should be able to change the class names with the tailwind functionality but it only does the name change. or maybe I have setup something wrong in my webpack which is making it behave as only changing the classnames and not have the tailwind functionality.

But yes, this is a much needed package.

[kissu]

@Strangersknowme obfuscation and namespacing are 2 totally different things.

You can totally set a custom prefix to avoid any conflicts.

[sntran]

For example, we visit https://tailwindcss.com/ , then open the developer tools and inspect the elements. Instantly, the layout and style of all those elements on the page can be guessed without even looking at the style panel on the right.

This is a weak argument. You are already looking at the developer tools. The DOM tree and the Styles panel are next to each other. You want to hide the actual class names, but the resulting styles are still there.

Not really sure why you want to hide either. Tailwind class names are pretty much mapped to individual styles.

[mohdlatif]

Most UI templates like Tailwind UI are images only for a reason.

It's important to note that even the original developers of Tailwind CSS obfuscate their classes on the Tailwind UI component page. This isn't about changing the internet with claims but about recognizing a practical measure that can make a difference.

Obfuscating classes won't provide absolute protection, but it does add a layer of complexity that can deter casual copying. When classes are complex and obfuscated, it requires more effort and time to decipher and replicate them, even with the help of tools and extensions designed to extract code from websites. This additional barrier can discourage some from copying the design outright.

Ultimately, obfuscation isn't about making something impossible to copy; it's about making it less convenient and more time-consuming, which can be a useful measure for those who want to protect their hard work.

[DamianGlowala]

I'm surprised no one mentioned potential decrease in size of browser requests serving .html and .css files containing Tailwind CSS. Obfuscated class names are very likely to be shorter compared to their original equivalents, making websites quicker to load (even if this is by a tiny bit!).

This sounds like a much stronger argument to me than preventing an easy copy-paste (which I also do agree with).

[kissu]

@mohdlatif guess this is the only viable reason to obfuscate something, even if protecting some CSS is not an amazing business idea some would argue. And with a small decipher curve as a whole.

@DamianGlowala not sure how obfuscation is supposed to help here. Do you mean that you could kinda wrap all of the files into 1 single chunky one? Not sure that this is helping, quite the opposite.
As for class length, since Tailwind is a utility framework (reminder: you do not need to re-declare a variable, you use it once everywhere rather than an obfuscated one that needs to be redefined again probably), you will only ship classes that you're using. Those classes might have some common words in them, like text, red, border etc, those will be compressed and hence removed from the final bundle in an efficient way. Potentially having some smaller (clashing even?) class names that will create more work for the browser to parse and execute is not gonna help anyhow. Since when 1 stripped character is better than less JS being executed client-side?

So no, [insert any random example of some war weapon that is 99% atrocious but COULD have some use-case in a very rare occasion for some people 1% of the time] is not the way to go when weighing pros/cons. 😂

Overall, when is having more CSS worse than having more JS?
Do I really need to pull some benchmarks for that one?

[DamianGlowala]

Let me refrain from commenting on majority of your response as it feels like we have a totally different understanding of the end goal, and instead present my vision on obfuscation in slightly more detail. I'd appreciate your comments on pros/cons of the below.

The following transformations would happen at build time (these are naive examples to prove my point; size savings might differ less or more):

• part of a minified HTML file served to the browser (approx. 12.9% reduction in size)

  BEFORE (558 chars):

  <div class="flex h-5 w-5 shrink-0 items-center justify-center rounded bg-white text-sm font-medium shadow">Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</div>
  

  AFTER (486 chars):

  <div class="a b c d e f g h i j k">Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</div>
  

• part of a minified CSS generated by Tailwind CSS for the above HTML (approx. 11.5% reduction in size)

  BEFORE (618 chars):

  .flex{display:flex}.h-5{height:1.25rem}.w-5{width:1.25rem}.shrink-0{flex-shrink:0}.items-center{align-items:center}.justify-center{justify-content:center}.rounded{border-radius:.25rem}.bg-white{--tw-bg-opacity:1;background-color:rgb(255 255 255 / var(--tw-bg-opacity))}.text-sm{font-size:.875rem;line-height:1.25rem}.font-medium{font-weight:500}.shadow{--tw-shadow:0 1px 3px 0 rgb(0 0 0 / 0.1),0 1px 2px -1px rgb(0 0 0 / 0.1);--tw-shadow-colored:0 1px 3px 0 var(--tw-shadow-color),0 1px 2px -1px var(--tw-shadow-color);box-shadow:var(--tw-ring-offset-shadow,0 0 #0000),var(--tw-ring-shadow,0 0 #0000),var(--tw-shadow)}
  

  AFTER (546 chars):

  .a{display:flex}.b{height:1.25rem}.c{width:1.25rem}.d{flex-shrink:0}.e{align-items:center}.f{justify-content:center}.g{border-radius:.25rem}.h{--tw-bg-opacity:1;background-color:rgb(255 255 255 / var(--tw-bg-opacity))}.i{font-size:.875rem;line-height:1.25rem}.j{font-weight:500}.k{--tw-shadow:0 1px 3px 0 rgb(0 0 0 / 0.1),0 1px 2px -1px rgb(0 0 0 / 0.1);--tw-shadow-colored:0 1px 3px 0 var(--tw-shadow-color),0 1px 2px -1px var(--tw-shadow-color);box-shadow:var(--tw-ring-offset-shadow,0 0 #0000),var(--tw-ring-shadow,0 0 #0000),var(--tw-shadow)}
  

[kissu]

Not sure why ignoring it. 🤷🏻
Especially since what I wrote was referring to the given 486 chars part as we both meant it.

Again, once compressed I don't see how this is a big deal overall, quite the opposite even if not done well (and in a less naive/lucky use case).
This is also some kind of obfuscation indeed, but mostly what I would call uglification + minification. I have no issues with the combo of those 2, but the issue is that most people want to hide their entire page by doing some heavy computational JS work, not a clean build step.

Some of those people are juniors devs maybe, but from my experience, 90% of the folks that I met were looking for an actual obfuscation, something like this pretty much for a hello world for the purpose of hiding their code.

This is not acceptable and utter garbage. Will die on that hill any day. 😌

As for the ugly + mini part, tools like that existed for Webpack already, and are more of a builder's responsibility IMO.
There is probably a way to do that already nowadays too, hence why I said it is not Tailwind's job to handle this.

PS: by reading a little more, looks like everyone does not agree on what obfuscation means in the CSS realm, aligning everyone to that term would be a good start. Then, there might be some issues and breaking things coming from that process, but it is not that trivial. Finally, not everyone will notice a lot of performance gains, if any.

PS2: after a quick search on that topic (not sure why I'm helping here), I found that this is not a common practice not a lot of people are even asking for it nowadays. There might be a good reason for such a move.
But yes, look on Vite's or PostCSS side and you'll find a package like this, that does pretty much what people want here. If it doesn't suit your needs, I again think that it's quite doable in Vite if you truly care.

Since most people will ship some bloated 3rd party script because the product team decided to do so and bring the whole cruiser of JS frameworks to the party, might not matter that much at the end of the day to save 2kB of non-blocking CSS for the sake of ease of debuggability.

PS3: oh nvm. 🙊 🔥 😭

[geanrt]

I'm an extension creator and particularly the business here only works on the basis of obfuscation, a lot of cheap copying being done for nothing and making our business get screwed... Indeed, Tailwind should think that we can somehow collaborate with this to improve the code for everyone who wants this and everyone wins, without getting ripped off.

That said, is there any more practical way to obfuscate Tailwind styles? 👍🏽

[geanrt]

Ihuuu, with ten minutes of research I found what I wanted https://github.com/sonofmagic/tailwindcss-mangle, 100% Ts project and also with Vite support to improve and efficient DEVELOPMENT... Now I can obfuscate a critical part of Tailwind in the project. Anyone who wants here again: https://github.com/sonofmagic/tailwindcss-mangle

[geanrt]

@geanrt I don't think it helps much, a toolbox in the browser can recreate your CSS perfectly fine, and it wouldn't surprise me other tools exists for this (including AI).
Obfuscation is useful to prevent collisions and such (it could make CSS classes shorter - speedup page rendering), but I don't think it helps preventing others copying your work.
A toolbox can also un-minify your JS scripts, just to give an example.

no one is saying that it will make it "impossible" for cheaters to reuse our code, it will just require a little more work for them and for me that's already enough

https://github.com/sonofmagic/tailwindcss-mangle 👈🏽 use this plugin and be happy

[kissu]

Are you sponsored or something with them?

[frederikhors]

@geanrt I don't think it helps much, a toolbox in the browser can recreate your CSS perfectly fine, and it wouldn't surprise me other tools exists for this (including AI).

Obfuscation is useful to prevent collisions and such (it could make CSS classes shorter - speedup page rendering), but I don't think it helps preventing others copying your work.

A toolbox can also un-minify your JS scripts, just to give an example.

Can you write the name of a toolbox please? @francoism90

[francoism90]

@frederikhors I was just referring to the browser's toolbox.

You can inspect a HTML-element, and it will present a computed version of it.
It isn't perfectly the same as source, but it's pretty close, as it's basically the final/render version.

I already give my opinion about this, I don't believe obfuscation works for hiding stuff. Maybe 10 years ago.

[geanrt]

Ihuuu, with ten minutes of research I found what I wanted https://github.com/sonofmagic/tailwindcss-mangle, 100% Ts project and also with Vite support to improve and efficient DEVELOPMENT... Now I can obfuscate a critical part of Tailwind in the project. Anyone who wants here again: https://github.com/sonofmagic/tailwindcss-mangle

[kissu]

Imagine, finding a build tool to solve such an issue. Who would have thought that it's more of a build tool approach needed here than a CSS utility framework? 🤷🏻‍♂️ (oh wait, I did say that)
Nah rather spam TW's team with some personal first world problems. 😂

PS: nice rare gem find btw. /s
It's in the OP description, what a dedication. 🙊

[geanrt]

And with a good number of collaboration 👆🏽