Photoshop CEP Extensions: When CEP Is Still the Right Answer

By Michael Peters · Published May 8, 2026 · Last updated May 8, 2026 · 7 min read

← Back to Blog

The honest framing

CEP — the Common Extensibility Platform — is the older HTML-panel framework Adobe used to host third-party panels in Creative Cloud applications before UXP. For Photoshop in 2026, CEP is unambiguously the legacy choice: UXP has been publicly available since 2021, the third-party UXP ecosystem is large and active, and Adobe’s strategic direction is unmistakable. Building a new Photoshop panel in CEP today is, in almost every case, the wrong call.

That said, CEP isn’t deprecated. Existing CEP extensions still load. Adobe continues to support the framework alongside UXP. There are specific cases where CEP is still the right answer — this post covers those, plus the migration path to UXP for everything else. The narrower UXP-vs-CEP comparison lives in UXP vs CEP extensions in Adobe Photoshop; this post is about the cases where CEP wins.

When CEP is still right for Photoshop

1. Maintaining an existing CEP panel

If you have a CEP panel in production, you don’t need to rewrite it in UXP just to be on the new platform. Existing CEP panels continue to load in current Photoshop versions. Rewriting working code without a substantive feature reason is rarely justified by user-facing benefit.

The reasonable rule: maintain the CEP panel as-is until you have a meaningful feature reason to touch it. When that reason arrives, evaluate whether the change is large enough to justify a UXP rewrite as part of the work, or small enough to apply in CEP. The "big rewrite" decision is forced by features, not by platform politics.

2. Node.js dependencies

CEP gives you Node.js inside the panel, with the full standard library and access to npm. UXP doesn’t. If your panel relies on:

• A Node native module (anything compiled, anything wrapping a system library — image processing libraries, custom hardware drivers, ML inference engines)
• A Node-only npm package without a browser equivalent (some specialised libraries for color science, codec wrappers, file format parsers)
• Node child-process orchestration (forking processes, piping stdin/stdout, running command-line tools)
• Direct filesystem access patterns that depend on Node’s fs module specifics

...a UXP rewrite isn’t a port — it’s a re-implementation. CEP remains the right answer until the re-implementation is justified by something more than platform alignment, or until Hybrid Plugins (UXP + native C++) become a path that covers your needs.

3. Deep CEP-only APIs

A handful of CEP-specific APIs don’t have UXP equivalents:

• The vfs cache for CEP extension assets
• Certain CEFCommandLine flags for fine-grained Chromium behaviour
• CEP-specific event hooks for application lifecycle events
• The CSEvent dispatch system for inter-extension communication
• Some advanced ExtendScript operations (deep colour management, certain History API states) that UXP’s native bindings haven’t covered yet

If your panel depends on any of these, UXP isn’t a drop-in replacement. The migration cost is the rewrite of whichever piece relies on those APIs — and until that rewrite is justified, CEP remains appropriate.

What CEP is, briefly

For readers who haven’t worked with CEP before: it’s a framework Adobe introduced in 2014 that hosts HTML panels inside Creative Cloud applications. A CEP extension is a folder of files: HTML page, CSS and JavaScript, an ExtendScript file that talks to the host, and a manifest XML. At runtime the panel runs inside CEFCommandLine (a Chromium webview embedded in Photoshop) and communicates with the document via the CSInterface JavaScript library, which evaluates ExtendScript code in Photoshop’s scripting engine.

The framework is mature and well-tooled. Chrome DevTools for the panel debug, the VSCode ExtendScript Debugger for the host code, ZXP signing for production distribution — the development workflow works cleanly. Most third-party Photoshop panels currently in production were originally CEP-based, though the migration to UXP has been steady.

The anatomy of a CEP extension for Photoshop

A minimal CEP extension is a folder with:

com.mapsoft.demo/
  CSXS/
    manifest.xml          <-- declares Photoshop as host
  index.html              <-- the panel
  js/
    CSInterface.js        <-- Adobe's host-comms library
    main.js               <-- panel logic
  jsx/
    host.jsx              <-- ExtendScript run in Photoshop

The manifest declares which Adobe applications the extension supports. For Photoshop, the host code is PHSP (or PHXS):

<HostList>
  <Host Name="PHSP" Version="[24.0,99.9]"/>
  <Host Name="PHXS" Version="[24.0,99.9]"/>
</HostList>

The two host codes cover the consumer Photoshop and the legacy "Extended" SKU; modern Photoshop versions still respect both for compatibility. The version range covers Photoshop 2023 onwards; adjust the lower bound for older support.

How a CEP panel talks to Photoshop

The bridge is CSInterface.js. The panel uses evalScript() to send ExtendScript strings to the host:

// In main.js (panel)
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 (ExtendScript)
function countLayers() {
  if (app.documents.length === 0) return '0';
  return app.activeDocument.layers.length.toString();
}

The CEP-vs-UXP architectural difference is here: in UXP the panel calls Photoshop’s API directly, no string-passing bridge. In CEP, every host operation goes through evalScript as a string. That’s the source of CEP’s performance overhead and the friction in production code.

Debugging

The debugging story is good. Add a .debug file mapping the extension ID to a port, and CEP exposes the panel’s webview to Chrome DevTools:

<ExtensionList>
  <Extension Id="com.mapsoft.demo.panel">
    <HostList>
      <Host Name="PHSP" Port="8088"/>
    </HostList>
  </Extension>
</ExtensionList>

Open chrome://inspect, attach to the listed port, full DevTools (breakpoints, network, performance, console). For the ExtendScript side, the VSCode "Adobe ExtendScript Debugger" extension provides breakpoints and stepping. Standard CEP-team debugging stack.

Set PlayerDebugMode to 1 in the registry (Windows) or defaults (macOS) for unsigned development extensions to load.

Packaging and signing — ZXP

For production distribution, package as a ZXP file — a signed ZIP archive. The signing tool is ZXPSignCmd, distributed by Adobe as part of the CEP SDK. The flow:

1. Generate a self-signed certificate (or use a code-signing certificate from a CA — better trust prompts at install).
2. Run ZXPSignCmd -sign <extension-folder> <output.zxp> <cert.p12> <cert-password>.
3. Distribute the .zxp; users install via Anastasiy’s Extension Manager or similar.

Distribution channels

Same channels as UXP plugins:

• Adobe Exchange / Creative Cloud Marketplace — the official discovery channel; reaches the largest audience but requires Adobe’s review.
• Direct download — sell or distribute the ZXP from your own site; users install with Anastasiy’s. Right for niche enterprise tools.
• Enterprise side-loading — deploy ZXPs across an organisation via SCCM, Jamf, or Intune.

Migration path to UXP

For a CEP-to-UXP migration, four practices make the move cheap:

1. Keep ExtendScript thin in the CEP version. Each ExtendScript function should be a thin wrapper around a host API call. UI logic, state, and async work belong in the panel’s JavaScript. When you migrate, the ExtendScript layer goes away (UXP calls the host directly); the panel JavaScript ports almost as-is.
2. Avoid Node.js where you can. Use browser-standard APIs (fetch instead of require('https'), Web Workers instead of child processes). The unavoidable Node.js cases are the parts you’ll genuinely have to rewrite — or where Hybrid Plugins (UXP + C++ native) might be the right successor.
3. Use Spectrum Web Components. Adobe’s component library works in CEP today and is the recommended UI in UXP. Building against Spectrum now means the visual design ports as-is.
4. Modularise host calls behind a single comms layer. Wrap all evalScript calls in one host-comms module. When you migrate, you replace that one module with direct UXP API calls; the rest of the panel doesn’t change.

The honest take

CEP for Photoshop in 2026 is the legacy framework that still has a role — not because it’s the strategic future (it isn’t) but because the migration cost to UXP is real and the CEP panels in production today work. Don’t rewrite a working CEP panel for the sake of being on the new platform. Don’t start a new Photoshop panel project in CEP unless you have one of the three justifications above.

The Photoshop CEP-to-UXP migration is the most advanced of any Creative Cloud application. The ecosystem has been moving for years; the tooling is mature; the developer reasons are well understood. CEP will keep loading. Plan migrations on feature-driven schedules, architect new CEP work to be migration-friendly, and default to UXP for anything genuinely new. For Node.js-dependent cases, evaluate Hybrid Plugins as the modern successor.