vc_raw_html Shortcode

Use native Custom HTML in Gutenberg, or vc_raw_html for existing Page Builder content. Both accept authored HTML using the theme's existing helpers; neither creates a new frontend stylesheet.

The attributes below match the current Page Builder controls and public output. Use raw syntax only for reviewed content that cannot be maintained through the visual controls.

In the backend builder, use the element's code action to edit content in the dedicated full-screen CodeMirror modal. The standard edit action remains available for the element ID, extra class, and responsive visibility settings. Other shortcode parameters that use a code editor are not moved into this modal.

Native HTML in Gutenberg

This is for editors who maintain small, reviewed HTML fragments. Prefer Paragraph, Heading, List, Image and the dedicated interactive blocks when they can express the content. Use Code to display source code rather than render it.

  1. Open Pages → All Pages or Posts → All Posts, then edit the intended item.
  2. Open the block inserter and select Custom HTML.
  3. Enter markup in HTML mode. Put IDs, helper classes and responsive visibility classes directly on the relevant elements.
  4. Choose Preview in the floating block toolbar to inspect the passive result with the theme's current typography, palette, grid and basic component helpers. Choose HTML to resume editing.
  5. Optionally open Organization → Administrative name in the block sidebar. This name identifies the block in List View; it is not public content.
  6. Save the draft, reload the editor and open the page preview. Check links, responsive layout and any interactive component there.

For example:

<div class="p-2 bg-main-2 text-main-13">
    <p class="fs-125">A short message using existing theme helpers.</p>
</div>

The block is static: WordPress saves the authored markup without an additional POM presentation wrapper. It can sit directly inside a Section without a Row or Column. The sidebar explains HTML permissions and preview limits; it does not add typography, CSS or JavaScript panels.

Preview does not run scripts, styles, forms or embedded frames. Its inert frame prevents interaction and isolates IDs from the editor. Large sources remain editable even when the preview limit is reached. The page preview remains the place to check supported frontend behavior. Preview limitations do not remove source from the saved block.

WordPress permissions still control allowed HTML when saving. Users without unfiltered_html have unsupported markup filtered by WordPress. Removing separate CSS/JavaScript panels is an authoring choice, not a security boundary: an authorized unfiltered author can still enter those tags in the HTML source. Review such content carefully and prefer the theme's managed assets.

Legacy usage

The Page Builder's HTML editor encodes the enclosed content as Base64 of URL-encoded HTML. Preserve this encoding when maintaining stored shortcodes. Do not place ordinary HTML directly between the shortcode tags or pass it as a content attribute.

[vc_raw_html]JTNDcCUzRUhlbGxvJTNDJTJGcCUzRQ==[/vc_raw_html]

This example renders <p>Hello</p>. The registered shortcode remains available when the Page Builder administration interface is disabled.

Attributes

Attribute Default Accepted values Purpose
device_visibility — String unless stated otherwise Applies the selected responsive visibility rule.
el_id — Valid unique HTML ID Enter element ID (Note: make sure it is unique and valid according to w3c specification).
el_class — String unless stated otherwise Style particular content element differently - add a class name and refer to it in custom CSS.

Verification

The legacy renderer decodes the content and applies the theme's HTML allowlist, including allowed attributes and URL protocols. Passive formatting such as sup, sub, code, kbd and bdo is retained; event-handler attributes and executable URL protocols are filtered. An optional ID, extra class or visibility setting creates the existing legacy wrapper. In native HTML, place those properties directly on authored elements instead.

Supported theme markup, such as a tooltip with data-toggle="tooltip", participates in conditional asset discovery whether it appears in native HTML or the encoded legacy content. Plain HTML requests no extra assets. Discovery does not execute the source, nested shortcodes, or custom render filters; it cannot infer arbitrary third-party dependencies.

If an interaction is absent after changing HTML, save the page and clear its page cache. For a site-wide refresh, use the documented asset discovery maintenance. Review any notice about unusually large raw HTML sources rather than assuming all their dependencies were discovered.

Confirm the saved source, frontend formatting and links after reloading. Differences limited to script execution or embedded content in the passive editor preview are expected. If WordPress removes markup on save, review the author's permissions and use a dedicated supported block rather than bypassing filtering.