Open a typical Divi services page in the Layers view and count the pieces. One section, one row, three columns, three icon modules, three heading modules, three text modules, a divider, and a button. That is roughly twenty things to style, and most spacing decisions get made again for every breakpoint Divi exposes.

On a lot of pages I do not build that. I drop in one full width Divi code module and write the entire section as plain HTML and CSS.

This is not the way to build every Divi site, and I want that clear before anything else. It is a tradeoff, and the cost lands on the client rather than on me. Most write-ups of this technique skip that half, which is exactly what makes them useless. So here is the honest version: what the approach buys, what it takes away, and the rule I use to decide which sections get it.

What Actually Goes Inside One Divi Code Module

The Code Module is a normal Divi module that accepts raw code instead of preset fields. According to the Elegant Themes documentation, it takes HTML, CSS, JavaScript, shortcodes, and third-party embeds, with CSS wrapped in style tags and JavaScript wrapped in script tags. It still gets Divi design controls for background, spacing, sizing, and border, and it still gets a CSS ID and classes on the Advanced tab.

What I paste into it is a complete section. One semantic section element as the full width wrapper, a max width container centered inside it, and the content laid out with CSS Grid or Flexbox. Icons are inline SVG, never an image request. Nothing loads from a CDN.

The styles come in two layers and only one of them lives in the module. Shared things like buttons, section padding, and heading scales sit in global CSS that I deploy through a snippets plugin rather than a child theme. Only the styles unique to that page go inside the Code Module, scoped under a single class so they cannot leak into the theme.

Type sizes are set with clamp rather than a value per breakpoint. According to MDN, clamp has been available across browsers since July 2020, so there is no support argument left against it.

That scoping rule is what keeps this survivable. Every selector in the module starts with the section own class, so a heading rule reaches the headings in that section and nothing else on the site. Remove the module and the styles leave with it, which is what makes the section behave like a component instead of a site-wide edit.

What It Buys: Markup I Wrote, and Type That Scales Without Breakpoints

Three things, and they are worth naming precisely rather than as a vague feeling of control.

The first is the markup itself. A designed section built from stacked modules arrives on the page wrapped in whatever structure the builder needs to make its own settings work. When I write the section, the element order is the element order, the class names mean something, and the CSS selectors stay short. Debugging stops being a guessing game about which generated wrapper is adding the padding.

The second is fluid sizing. I set headings and section spacing with clamp, so one declaration covers every screen instead of a separate value at each breakpoint. I have written up why fluid typography beats a breakpoint table, and the argument gets stronger the more elements a section carries.

The third is portability, and it is the one I did not expect to care about. A section is a text file. I can put it in version control, diff two revisions to see exactly what changed, and move it to another site by pasting it. A layout built from modules lives in the database and travels through export files.

I build most of these with Claude as my collaborator, and the designs and functionality it comes back with are genuinely good. That is only true because the output is plain HTML and CSS. Handing an AI a Divi layout to restructure is a different and much worse job than handing it a text file.

What It Costs: The Client Cannot Edit It in the Builder

Here is the part that decides everything.

Open that page in the Visual Builder as the client and the section is a box of code. They can move it, change its background, and set its padding. They cannot change a headline, swap a photo, or fix a typo without editing HTML. Divi design controls apply to the module container, not to the markup inside it.

For a developer that is a shrug. For a client who was sold a site they can maintain, it is a broken promise, and it usually arrives six months later as an email asking why they cannot change three words.

This is not a small caveat. It is the whole reason the technique needs a rule attached. A services page where the copy is signed off and frozen is a good candidate. A staff page where someone leaves every quarter is not. An events banner the client updates monthly is not. The question is never whether I can build it in code. It is whether anyone but me will ever need to change it.

There is a second, smaller cost. Divi module settings for that content stop being available, so anything a module would have given you for free, such as per-element responsive visibility or hover states configured in the interface, has to be written by hand. That is fine when you were going to write the CSS anyway. It is wasted effort when a plain Text module would have done the job.

Divi 5 Moved the Line, and It Moved Toward Native Modules

Divi 5 rebuilt the builder from the ground up, and one of the additions changes when reaching for a Code Module is the right call. Custom HTML Wrappers add two fields, HTML Before and HTML After, in the HTML option group on every element Advanced tab. According to Elegant Themes, they let you open a custom tag before an element output and close it after, so you can wrap an existing Button or Module Group in your own div without adding a separate module at all. The same option group carries an Element Type dropdown for choosing a semantic tag such as nav, section, or article.

That kills a whole category of Code Module abuse. Anyone who was dropping an empty Code Module in just to open a wrapper div now has a native place to do it, with cleaner output and no orphan module left behind.

Elegant Themes is direct about the split in their own comparison table. Custom HTML wins on wrapping other elements, integration level, markup cleanliness, and maintainability. The Code Module wins two rows: best for standalone code, and learning curve. They also say plainly that Divi 5 does not replace the Code Module.

Read that honestly and it narrows the case rather than ending it. Small injections attached to an existing module belong in wrappers. A whole designed section that has no Divi module underneath it still belongs in a Code Module, because there is nothing to wrap.

My Rule: Ownership Decides, Not Difficulty

Static, designed, developer-owned sections go in a Code Module. Anything the client will want to reword stays as native Divi modules. That is the whole rule, and it has held up on every site where I have used this.

Three conventions make it survivable in practice.

One Code Module per page, not five. A page split across several code blocks is worse than either extreme. The styles interleave, the section order gets hard to follow in the builder, and you lose the single text file that made the approach portable in the first place.

A marked placeholder where dynamic content goes. Functional pieces stay in Divi. A contact form, a WooCommerce grid, a filterable directory, a blog loop: those get built as Divi Library items or shortcodes, and the HTML carries a clearly commented slot where the shortcode is dropped. The Code Module renders shortcodes, so a dynamic component sits inside a static shell without either one fighting the other.

CSS scoped to one class, always. Every rule in the module starts with the section own class. No bare element selectors, no styling headings globally from inside a page section. This is the rule that stops a page-level paste from turning into a site-wide bug three months later.

Where the rest of the CSS lives matters too. Elegant Themes documents several places to put custom CSS in Divi 5: Theme Options for site-wide rules, Page Settings for a single page, and the CSS option group on an individual element. Site-wide styles belong in one of those or in a snippet, never duplicated inside a page section.

Two Things People Get Wrong About This

It Is Not Automatically Faster

Fewer modules means a lighter DOM, and Elegant Themes points at reduced structural layers as a performance benefit of writing your own markup. That is real, but it is not a speed trick. A section written badly by hand can easily be heavier than the same section built from modules. The gains I actually measure come from not loading images I did not need and not shipping icon fonts, and those are choices rather than consequences of using a Code Module.

Divi 5 Did Not Retire the Code Module

The Custom HTML Wrappers coverage set off a round of assumptions that the Code Module was on the way out. Elegant Themes says the opposite in the same article that introduces wrappers: the two are complementary, and the Code Module remains the right choice for self-contained blocks. Their own scoring table gives it the win for standalone code.

Questions I Get About This

Can You Put Shortcodes Inside a Divi Code Module?

Yes. Elegant Themes lists shortcodes as a supported use of the Code Module, and it is how the static shell and dynamic insert pattern works. Leave a commented slot in the HTML and paste the shortcode there, so a Divi Library form or a custom directory renders inside a section you wrote by hand.

Where Should the CSS for a Divi Code Module Go?

Page-specific styles go inside the module in a style tag, scoped to the section own class. Site-wide styles go in Theme Options or a code snippet. Nothing shared should ever be declared inside a page section, because then you have two copies and they will drift apart.

Will My Client Still Be Able To Edit the Section?

Not in the Visual Builder. They can move the module and restyle its container, but the text and images inside are HTML. That is the real cost of the approach, and it is why anything a client edits regularly should stay a native Divi module.

Does This Hurt SEO?

No, as long as the markup is right. Search engines read the rendered HTML either way. Writing it yourself gives you more control over heading order and semantic elements than a stack of modules does, provided you keep a single H1 and keep heading levels in sequence.

The One Thing To Take Away

Ask who owns the section. Not who can code it, not which approach is more elegant, but who is going to open it in six months and change three words. If that person is you, a Divi code module gives you markup you control, type that scales without a breakpoint table, and a section you can move between sites as a text file. If that person is the client, build it with modules and stop thinking about it.

Getting this wrong in the second direction is the expensive mistake. A developer-owned section built from modules is a mild annoyance. A client-owned section locked inside a code block is a support ticket every month for the life of the site.

Sources

• The Code Module Divi 5, Elegant Themes Help Center
• Code Modules vs Custom HTML Wrappers In Divi 5, Elegant Themes
• Where to Add Custom CSS Code in Divi 5, Elegant Themes Help Center
• clamp() CSS function, MDN Web Docs