Illustrator CEP Extensions: HTML Panels for Production Workflows
CEP is the framework Illustrator users actually have for building persistent panels. Mature, fully documented, used in production by most third-party Illustrator panels shipping today — and, for the foreseeable future, the only public option for that job. Here’s how it works, how to ship one, and how to plan for the eventual UXP migration.
What CEP is, briefly
CEP — the Common Extensibility Platform — is the framework Adobe uses to host HTML-based panels inside Creative Cloud applications. A CEP extension is a folder of files: an HTML page, the CSS and JavaScript that drive it, an ExtendScript file that talks to the host application, and a manifest XML that tells Illustrator how to load it. At runtime the panel runs inside CEFCommandLine (a Chromium webview embedded in Illustrator) and communicates with the document via the CSInterface JavaScript library, which evaluates ExtendScript code in Illustrator’s scripting engine.
The framework first shipped in 2014 (replacing the older Flash-based panels) and has been the standard panel framework across Photoshop, Illustrator, InDesign, Premiere, and the rest of the suite since. It’s well-documented, well-tooled, and used by most third-party Illustrator panels currently in production — from cartographic packages like MAPublisher to specialised packaging tools and enterprise asset browsers.
Why CEP is still the right answer for Illustrator in 2026
Adobe’s strategic direction is UXP — the modern replacement for both CEP and ExtendScript. UXP is publicly available for Photoshop and InDesign. For Illustrator, UXP remains internal to Adobe as of 2026, with no published API or release timeline for third-party developers. The honest practical implication: if you need a panel for Illustrator today, CEP is the only public option. We cover the current state in detail in UXP for Illustrator: current status.
The good news is that Adobe has not signalled CEP deprecation for Illustrator. When UXP launched for Photoshop, CEP continued to load alongside it for several years afterwards — the expectation is the same for Illustrator. A CEP panel built today will continue to work when public UXP for Illustrator does ship, and probably for several years after that. Plan a migration; don’t rebuild speculatively.
The anatomy of a CEP extension
A minimal CEP extension is a folder with three things in it:
com.mapsoft.demo/
CSXS/
manifest.xml <-- tells Illustrator about the extension
index.html <-- the panel itself
js/
CSInterface.js <-- Adobe’s host-comms library
main.js <-- your panel logic
jsx/
host.jsx <-- ExtendScript that runs in Illustrator
The folder name is the extension’s ID. The CSXS/manifest.xml file declares which Adobe applications the extension supports, what panel name to display, what HTML file to load, and what permissions to grant. A skeleton manifest:
<?xml version="1.0" encoding="UTF-8"?>
<ExtensionManifest Version="11.0" ExtensionBundleId="com.mapsoft.demo"
ExtensionBundleVersion="1.0.0"
ExtensionBundleName="Mapsoft Demo Panel">
<ExtensionList>
<Extension Id="com.mapsoft.demo.panel" Version="1.0.0"/>
</ExtensionList>
<ExecutionEnvironment>
<HostList>
<Host Name="ILST" Version="[28.0,99.9]"/>
</HostList>
<LocaleList>
<Locale Code="All"/>
</LocaleList>
<RequiredRuntimeList>
<RequiredRuntime Name="CSXS" Version="11.0"/>
</RequiredRuntimeList>
</ExecutionEnvironment>
<DispatchInfoList>
<Extension Id="com.mapsoft.demo.panel">
<DispatchInfo>
<Resources>
<MainPath>./index.html</MainPath>
<ScriptPath>./jsx/host.jsx</ScriptPath>
</Resources>
<UI>
<Type>Panel</Type>
<Menu>Mapsoft Demo</Menu>
<Geometry>
<Size><Height>400</Height><Width>320</Width></Size>
</Geometry>
</UI>
</DispatchInfo>
</Extension>
</DispatchInfoList>
</ExtensionManifest>
Two non-obvious parts. Host Name="ILST" is Adobe’s four-letter code for Illustrator. The version range [28.0,99.9] covers Illustrator 2024 onwards — you’ll need to update the lower bound for older support, and check the upper bound when new Illustrator versions ship.
How the panel talks to Illustrator
The bridge is CSInterface.js, a thin JavaScript library Adobe ships with every CEP installation. The panel includes it, instantiates a CSInterface object, and uses evalScript() to send ExtendScript strings to the host:
// In main.js (the panel side)
var cs = new CSInterface();
document.getElementById('countLayers').addEventListener('click', function () {
cs.evalScript('countLayers()', function (result) {
document.getElementById('output').textContent =
'Document has ' + result + ' layers';
});
});
// In jsx/host.jsx (the ExtendScript side)
function countLayers() {
if (app.documents.length === 0) return '0';
return app.activeDocument.layers.length.toString();
}
Three things worth knowing about the bridge:
- Everything crosses the bridge as a string. The argument to
evalScriptis a string, and the callback receives a string. For anything more complex than a number or a name, the convention is to JSON-serialise on the ExtendScript side and JSON-parse on the panel side. - The call is async on the panel side. The callback fires when the ExtendScript finishes. From the panel’s perspective, the document operation is non-blocking, which is what makes a CEP panel feel responsive even when the underlying ExtendScript is doing real work.
- Keep ExtendScript thin. The panel is the right place for UI logic, state management, async work, and anything that doesn’t directly touch the Illustrator document. The ExtendScript layer should be the smallest set of host-API calls that the panel needs — ideally a single function per logical operation. This is also what makes the eventual UXP migration cheap: the panel’s JavaScript ports almost as-is, and the ExtendScript layer is replaced by direct UXP API calls.
Debugging
The development debugging story is genuinely good. Add a .debug file to the extension folder and CEP exposes the panel’s webview on http://localhost:<port>, which Chrome (or Edge, or any Chromium browser) can attach to and debug with full DevTools — breakpoints, console, network tab, performance profiler. The contents of .debug map extension IDs to ports:
<?xml version="1.0" encoding="UTF-8"?>
<ExtensionList>
<Extension Id="com.mapsoft.demo.panel">
<HostList>
<Host Name="ILST" Port="8088"/>
</HostList>
</Extension>
</ExtensionList>
For the ExtendScript side, the VSCode "Adobe ExtendScript Debugger" extension gives breakpoints and stepping. The combination — Chrome DevTools for the panel, VSCode for the ExtendScript — is the production debugging setup most CEP teams settle on.
One CEP-specific gotcha: by default, Illustrator only loads signed CEP extensions. For unsigned development extensions you need to set the PlayerDebugMode registry key (Windows) or defaults setting (macOS) to 1. Adobe documents this; missing it is the most common reason a fresh CEP install "doesn’t appear in the Extensions menu".
Packaging and signing — ZXP
For production distribution, a CEP extension is packaged as a ZXP file — a signed ZIP archive containing the extension folder and a signature block. Adobe requires that all production CEP extensions be signed with a certificate. The signing tool is ZXPSignCmd, which Adobe distributes as part of the CEP SDK.
The basic flow:
- Generate a self-signed certificate (or use a code-signing certificate from a CA — better for trust prompts).
- Run
ZXPSignCmd -sign <extension-folder> <output.zxp> <cert.p12> <cert-password>. - The resulting ZXP installs cleanly via Anastasiy’s Extension Manager or any ZXP installer utility.
Distribution channels
Three production channels for CEP distribution:
- Adobe Exchange / Creative Cloud Marketplace. The official discovery channel inside Creative Cloud. Good for free or paid panels with broad audiences. Requires Adobe’s review process.
- Direct download. Sell or distribute the ZXP from your own site; users install with Anastasiy’s or similar. The right channel for niche enterprise tools, demo panels, and anything that needs a faster iteration cycle than Adobe’s review allows.
- Enterprise side-loading. For internal tools, deploy ZXPs across an organisation via SCCM (Windows), Jamf (Mac), or Intune. The panel appears in Window → Extensions on every desktop without per-user installation.
Architecting for the UXP migration
When public UXP for Illustrator does eventually arrive, the migration cost depends almost entirely on how cleanly the original CEP panel separated UI from host communication. Four practices that make the eventual port cheap:
- Keep ExtendScript minimal. Each ExtendScript function should be a thin wrapper around a host API call. UI logic, state, and async work belong in the panel.
- Avoid Node.js where you can. CEP gives you Node.js inside the panel; UXP doesn’t. Use
fetchinstead ofrequire('https'); use Web Workers instead of Node child processes; avoid native modules entirely. - Use Spectrum Web Components. Adobe’s component library works in CEP today and will be the recommended UI in UXP. Building against Spectrum now means the visual design ports as-is.
- Modularise host calls. Wrap all
evalScriptcalls behind a single host-comms module. When UXP launches, you replace that one module with direct UXP API calls; the rest of the panel doesn’t change.
The honest take
CEP gets a bad press in extensibility discussions because it’s the legacy framework Adobe is migrating away from. For Illustrator in 2026, that framing is misleading: there is no production-grade alternative for third-party panels. CEP is mature, well-documented, well-tooled, and runs production workloads at scale. The migration to UXP is a future-tense problem, and the right way to manage it is architectural discipline now, not waiting for a platform that hasn’t opened up.
If you have a workflow that needs a persistent Illustrator panel today — a settings interface, an asset browser, a search-and-replace tool, a database-backed brand swatch picker — CEP is the answer. Build it cleanly, modularise the host comms, and the eventual UXP port will be a weekend rather than a rewrite.
Related Articles
UXP for Illustrator: Current Status
The honest current state of UXP for Illustrator and what to use instead — ExtendScript, CEP, the C++ SDK.
Combining Illustrator Extension Technologies
How ExtendScript, CEP, UXP, and the C++ SDK fit together — the comparison table and decision flow.
Adobe CEP: Common Extensibility Platform Guide
The cross-application introduction to CEP — how it works in Photoshop, InDesign, and the rest of the Creative Cloud suite.
Need an Illustrator Panel?
Mapsoft builds production CEP panels for Illustrator — from internal asset browsers to commercial extensions distributed via the Adobe Marketplace.
Mapsoft is an Adobe affiliate. We may earn a commission on Adobe purchases made through these links, at no extra cost to you.