UXP for InDesign: The Modern Extensibility Platform

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

← Back to Blog

The honest summary

UXP — Adobe’s Unified Extensibility Platform — is the modern replacement for the older CEP and ExtendScript stack. For InDesign, UXP has been publicly available since v18.5 (2023), with UXP v8.0 shipping in InDesign v20.0. The third-party UXP plugin ecosystem is active, the developer tooling is mature, and Adobe’s long-term direction is unambiguous: for new InDesign panel work in 2026, UXP is the right answer.

That’s the opposite of the story for Illustrator, where UXP remains internal to Adobe and CEP is still the only public option. InDesign got there first, alongside Photoshop (see UXP vs CEP for Photoshop), and the difference is real: if you’re starting a new InDesign panel project today, default to UXP and only step back to CEP for specific reasons.

What UXP is, briefly

The strategic case for UXP is straightforward. CEP panels run in a Chromium webview but call ExtendScript (an ES3 dialect from the 1990s) to talk to the host application. UXP unifies the two: a single ES2018+ JavaScript runtime with modern features, a sandboxed execution environment, direct access to the InDesign API without a marshalling bridge, and the Spectrum Web Components library for native-looking UI. Concretely:

• Modern JavaScript. async/await, modules, classes, the standard library you’d use writing any other JavaScript application in 2026.
• Direct host API. No CSInterface bridge, no string-marshalling between panel and ExtendScript. Your JavaScript calls InDesign DOM methods directly.
• Spectrum components. A native-looking UI library so panels match Adobe’s product design without hand-rolled styling.
• Better security and isolation. Each plugin runs in its own isolated JavaScript context, sandboxed by the OS, with explicit permission requests for filesystem and network access.
• Better performance. No webview overhead and no IPC round-trips on every API call.
• Hot reload and modern dev tools. The UXP Developer Tool provides Chrome DevTools-style debugging, hot reload, and a one-click package step.

Why InDesign was an early UXP target

Photoshop got UXP in 2021. InDesign followed in 2023 with v18.5. Illustrator, as of 2026, still hasn’t opened it up publicly — the gap between InDesign and Illustrator on UXP is now several years. Reasonable inference for why InDesign was prioritised:

• Active third-party ecosystem. InDesign has a large and active third-party plugin ecosystem — editorial tools, asset management bridges, multilingual support panels, brand-style enforcement — all of which need a forward-looking platform to invest against. Keeping that ecosystem on CEP indefinitely was untenable.
• Server adjacency. InDesign Server (the headless rendering engine for high-volume publishing) shares architecture with the desktop. Modernising the desktop extensibility surface set up the path for similar improvements on Server.
• Editorial workflows demand richer panels. The kinds of panels InDesign needs — live data binding, web service integration, complex multi-step UIs — benefit more from UXP’s capabilities than the simpler tool-style panels common in some other apps.

Whatever the priority logic, the practical effect is that InDesign UXP is mature in 2026: documented, tooled, and used in production by serious vendors.

When to still use CEP for InDesign

UXP is the default for new work, but CEP isn’t deprecated. Three cases where CEP is still the right answer:

1. Legacy panels in production. Existing CEP panels continue to load in current InDesign versions. Rewriting a working CEP panel in UXP for the sake of being on the new platform is rarely justified by the user-facing benefit. Migrate when you have a substantive feature reason to touch the panel.
2. Node.js dependencies. CEP gives you Node.js inside the panel; UXP doesn’t. If your panel relies on a Node native module, a Node-only library, or child-process orchestration, the migration to UXP requires rewriting that piece (often using browser-standard fetch and Web Workers) rather than copying it across.
3. Deep CEP-only APIs. A handful of CEP-specific APIs (vfs caches, certain CEFCommandLine flags, CEP-specific event hooks) don’t have UXP equivalents. If your panel relies on them, plan a rewrite of that piece, not a port.

The full CEP-for-InDesign treatment lives in InDesign CEP extensions — what CEP still does well, when to keep using it, and how to architect a future UXP migration cheaply. For the broader picture of how ExtendScript, UXP, CEP, and the C++ SDK fit together, see Combining InDesign Extension Technologies.

Getting started: a worked example

The fastest path from "I want to build a UXP panel" to "I have one running in InDesign" is the UXP Developer Tool. Install it from Adobe Creative Cloud, create a new plugin from a template, and you’re minutes from a working panel.

Manifest

Every UXP plugin has a manifest.json that declares which Adobe applications it supports, what permissions it requires, and where the entry point is. A minimal InDesign manifest:

{
  "manifestVersion": 5,
  "id": "com.mapsoft.demo",
  "name": "Mapsoft Demo Panel",
  "version": "1.0.0",
  "main": "index.html",
  "host": [
    {
      "app": "indesign",
      "minVersion": "20.0"
    }
  ],
  "entrypoints": [
    {
      "type": "panel",
      "id": "demoPanel",
      "label": { "default": "Mapsoft Demo" },
      "minimumSize": { "width": 320, "height": 400 }
    }
  ],
  "requiredPermissions": {
    "localFileSystem": "plugin",
    "network": { "domains": "all" }
  }
}

The panel UI

The panel itself is HTML/CSS/JS. Spectrum Web Components give you Adobe-styled UI elements out of the box:

<!-- index.html -->
<!DOCTYPE html>
<html>
<head>
  <link rel="stylesheet" href="https://jspm.dev/@spectrum-web-components/styles/typography.css">
  <script type="module" src="main.js"></script>
</head>
<body>
  <sp-button id="countLayers">Count layers in active document</sp-button>
  <p id="output"></p>
</body>
</html>

Talking to InDesign

The panel calls the InDesign DOM directly — no ExtendScript bridge:

// main.js
const { app } = require('indesign');

document.getElementById('countLayers').addEventListener('click', () => {
  const out = document.getElementById('output');
  if (app.documents.length === 0) {
    out.textContent = 'Open a document first.';
    return;
  }
  const doc = app.activeDocument;
  out.textContent = `Document has ${doc.layers.length} layers.`;
});

That’s a full working UXP panel. The structural difference from CEP is what’s not there: no CSInterface, no evalScript string-passing, no separate ExtendScript file. The panel’s JavaScript is the panel’s logic.

Common patterns

Beyond a simple button-and-output panel, three patterns come up frequently:

Custom panels with Spectrum components

Spectrum Web Components are available via JSPM or bundled with the plugin. <sp-button>, <sp-textfield>, <sp-picker>, <sp-dialog> — the full set covers most panel UI needs without hand-rolled CSS, and the components match Adobe’s product design automatically.

Contextual menus

UXP plugins can register entries in InDesign’s contextual menus. The plugin manifest declares the menu commands, and the JavaScript handles them when invoked — the same pattern as panel actions, just triggered from a different surface:

// In the entrypoints section of manifest.json:
{
  "type": "command",
  "id": "applyBrandStyle",
  "label": { "default": "Apply brand style" }
}

// In main.js:
const { entrypoints } = require('uxp');
entrypoints.setup({
  commands: {
    applyBrandStyle() {
      // ... apply paragraph style to selected text ...
    }
  }
});

Event listeners

UXP exposes the InDesign event model directly. Listen for afterSelectionChanged, afterOpen, afterSave, and the rest:

const { app } = require('indesign');
app.eventListeners.add('afterSelectionChanged', (event) => {
  // Update the panel based on the new selection
});

Distribution

Three channels for production UXP plugins:

• Adobe Exchange / Creative Cloud Marketplace. The official channel inside Creative Cloud, with paid and free support. Reaches the largest audience but requires Adobe’s review process.
• Direct download. Distribute the .ccx file from your own site. Right for niche enterprise tools and faster iteration.
• Enterprise side-loading. Deploy via SCCM (Windows), Jamf (Mac), or Intune across an organisation. The plugin appears in Window → Plugins on every desktop without per-user installation.

How to track UXP version availability

UXP versions ship with InDesign versions, and feature availability is tied to the host version. Two reliable signals:

• Adobe Developer — UXP for InDesign — the official documentation, including the API reference per InDesign version.
• UXP Developer Tool changelog — lists which applications and which UXP versions ship in which host versions. When a feature you need was added in UXP v7.5, you can match that to the InDesign version that included it.

The honest take

UXP for InDesign is a genuinely better platform than CEP. Modern JavaScript, direct host API, mature tooling, an active third-party ecosystem — the strategic case Adobe has been making since 2020 actually delivered for InDesign, where (as of 2026) it hasn’t yet for Illustrator. The honest recommendation for new InDesign panel work is unambiguous: build with UXP unless you have a specific reason to step back to CEP. The reasons exist (legacy migrations, Node.js dependencies, CEP-only APIs), they’re real, and they’re narrower than they seemed two years ago.

If you’re an InDesign panel developer who’s been deferring the UXP move, the developer tooling and ecosystem maturity are now both at the point where the deferral costs more than the migration. And if you’re starting fresh, UXP is the only sensible default.