CEP vs UXP for Photoshop: What to Know in 2026

If you use Photoshop plugins or think about building one, you have probably seen CEP and UXP in release notes, forums, or developer docs. They are not the same kind of thing as ExtendScript (the older JavaScript dialect used in .jsx automation). CEP and UXP are panel and plugin platforms: the runtimes and rules that host HTML and JavaScript inside Photoshop. In 2026, understanding CEP vs UXP for Photoshop helps you choose tools, plan migrations, and set expectations for support and performance.

Adobe’s guide for CEP developers states that CEP will remain in Photoshop for some time but will at some point be deprecated and, eventually, removed, while UXP is where new extensibility work is headed. See UXP for CEP Developers on Adobe Developer for the full rationale.

CEP (Common Extensibility Platform) is Adobe’s long-standing stack for HTML-, CSS-, and JavaScript-based panels that run inside Creative Cloud apps. CEP extensions are the “classic” model many third-party panels still ship with: a manifest, a panel UI built with web tech, and integration with the host application.

According to Adobe, each CEP extension runs in its own Chromium-based web host, which is very resource intensive for Photoshop, especially when several extensions are open. The UI layer also does not talk to Photoshop directly: host automation is typically done with ExtendScript passed through EvalScript calls. In practice you end up with two JavaScript environments (modern JS in the panel and ES3-era ExtendScript in the host), which makes anything beyond simple parameters awkward and inefficient to pass between layers. CEP panels cannot use native host controls, so matching Photoshop’s look and behavior usually means heavy CSS work.

That combination is mature and widely deployed, which is why a large catalog of professional plugins still relies on CEP, even as Adobe steers new development toward UXP.

UXP (Unified Extensibility Platform) is Adobe’s newer foundation for plugins (panels, dialogs, and headless plugins) in Photoshop. UXP supports HTML and CSS for UI, and you can build simple or complex interfaces, including with React, as Adobe describes in the same UXP for CEP Developers overview.

Because UXP communicates directly with the host, the split between a Chromium UI process and EvalScript-driven host logic largely goes away for new plugins. Adobe’s CEP to UXP Technical Migration Guide stresses a unified modern JavaScript environment (V8) so panel UI and plugin logic share the same context, which means no evalScript bridge between two runtimes for that work. Adobe also highlights Spectrum (Spectrum CSS) for theme-aware interfaces that align across Creative Cloud, plus a plugin loader and debugger (the UXP Developer Tool) that is simpler than typical CEP workflows. For a new Photoshop extension in 2026, UXP is the default recommendation in Adobe’s documentation, even though many CEP extensions remain in daily use.

Runtime and architecture. CEP’s full Chromium per extension is a major cost in CPU and memory compared with UXP’s lighter, app-integrated model. Independent writeups aimed at teams planning migration, such as Why Migrating to Adobe UXP Now Is Critical (Andrew Zaikin, Medium, 2024), echo the same performance and security themes for real-world deployments.

APIs and migration. UXP plugin code follows UXP and Photoshop APIs, not a one-to-one map of every CEP + ExtendScript pattern. Adobe’s open CEP to UXP Technical Migration Guide is explicit: UXP is not a browser the way CEP’s CEF stack was, so complete feature parity is unlikely and there is no single mechanical port. The guide frames the work as a reconstruction that uses UXP’s strengths (performance, security, native-feeling UI) rather than a line-by-line migration. Teams should still budget for testing, API gaps, and rewritten file and network flows. Official entry points include Migrating to UXP in the Photoshop UXP docs (From CEP) and the GitHub guide above.

Security and file access (developer view). The same migration guide contrasts CEP’s broad disk and process reach with UXP’s sandboxed model: arbitrary filesystem access gives way to user consent, tokens, and sanctioned plugin locations, which is better for users but requires redesigning installers, presets, and automation that relied on window.cep.fs or process APIs.

UI consistency. UXP’s path to Spectrum-aligned panels contrasts with CEP’s non-native controls unless you invest in custom styling.

What you feel as a user. From the outside, both can look like “a panel in Photoshop.” The difference shows up in installation, Photoshop version support, stability after updates, resource use, and whether the vendor ships CEP, UXP, or both. For Apple Silicon Macs, Adobe’s migration guide notes an important detail: CEP is supported natively on Apple Silicon for Creative Cloud apps in general, but not for Photoshop specifically, so native Photoshop on M1/M2/M3 is a common pain point for legacy CEP extensions. One workaround Adobe mentions is running Photoshop in Rosetta so CEP extensions can still load. For native Apple Silicon Photoshop, vendors increasingly need a UXP build. Community discussion also appears in threads such as Plugins on Macs with Apple silicon chips (M1, M2) / CEP vs. UXP on the Pixelsucht forum, alongside vendor release notes.

Adobe treats UXP scripting as its own lane. Per the UXP Scripting overview, a script runs a single file for a task, then unloads, with simpler setup than a full plugin. Scripts can use UXP and Photoshop APIs (and batchPlay where the DOM still has gaps). Adobe’s migration guide positions batchPlay as the evolution of ExtendScript’s executeAction, with descriptor-style work moving toward action JSON idioms. Compared with ExtendScript, UXP scripting uses a modern JavaScript engine (ES6 and up) instead of ES3, which makes many automation tasks easier to express.

UXP plugins differ from scripts in ways that matter when you choose an approach: persistent panel UI, longer-lived behavior, plugin data storage, distribution (marketplace identity vs. loose script files), and broader module access. None of that replaces the high-level picture for readers who only need to know: CEP vs UXP is about how a commercial panel is hosted; ExtendScript vs UXP scripting is about which automation runtime you use, and UXP scripts are still not the same thing as UXP plugins.

Expect continued coexistence for a while: studios still run proven CEP tools, while new extensions increasingly target UXP. Adobe’s migration guide also reminds readers that many end users may not need to switch for years, while Photoshop on Apple Silicon without Rosetta is often the group that needs a UXP build first. Plan for Adobe’s stated end state: CEP deprecation and removal eventually, not “CEP forever.” If you rely on a specific plugin, check the vendor for UXP builds, Apple Silicon notes, and Photoshop version requirements. If you are evaluating custom development, start from UXP docs and the UXP Developer Tool, and treat the CEP to UXP Technical Migration Guide plus From CEP in Adobe’s docs as the technical backbone, not a promise of a one-click conversion.

Most creatives do not want to become extension platform experts. They want faster layouts, one-click setups, and fewer menus. Configurator Reloaded 2 is a Photoshop plugin focused on custom panels without building a CEP or UXP extension yourself: you drag and drop tools, menu items, actions, and workflow scripts into dockable panels and workspaces. If you do write automation, the built-in Script Editor supports running ExtendScript and UXP scripts from one place inside the plugin, so you can experiment without assembling a full CEP or UXP project first.

Up to three dockable panels in Configurator Reloaded 2 keep custom layouts next to native Photoshop UI.

The Script Editor in the plugin lets you create, run, and save scripts without shipping a standalone CEP or UXP extension.

If you want custom Photoshop panels and workflow shortcuts without maintaining your own CEP or UXP codebase, try Configurator Reloaded with the free trial and build your layout in minutes instead of weeks.

• UXP for CEP Developers (Adobe): why CEP is being retired and how UXP replaces it
• CEP to UXP Technical Migration Guide (Adobe, GitHub): deep technical migration notes, Apple Silicon vs Photoshop, file APIs, plugin types, batchPlay vs ExtendScript
• UXP Scripting (Adobe): scripts vs plugins vs ExtendScript
• Why Migrating to Adobe UXP Now Is Critical (Andrew Zaikin, Medium): migration FAQ and practical reasons teams move early
• Plugins on Macs with Apple silicon / CEP vs. UXP (Pixelsucht forum): community discussion for Mac users