Modular And On-demand Renderers

The additive v3 standard profile, CLI plan, measured closure budget, and full-cutover blockers are documented in V3 Modular Profiles.

Minimal Import

For a PDF-only Vue 3 product:

npm install @file-viewer/vue3 @file-viewer/renderer-pdf

import { pdfRenderer } from '@file-viewer/renderer-pdf'

const options = {
  rendererMode: 'replace',
  renderers: [pdfRenderer]
}

This path is bundler-neutral and works in Webpack, Rspack, Rollup, Umi, classic multi-page apps, and micro-frontends. Vite projects can add the plugin to generate and inject the renderer import automatically:

npm install -D @file-viewer/vite-plugin

import { defineConfig } from 'vite'
import { fileViewerRenderers } from '@file-viewer/vite-plugin'

export default defineConfig({
  plugins: [
    fileViewerRenderers({
      formats: ['pdf'],
      copyAssets: true,
      chunkStrategy: 'renderer'
    })
  ]
})

copyAssets copies the offline payload that the installed packages provide. @file-viewer/renderer-pdf owns @fontsource-variable/noto-sans-sc as a runtime dependency, so direct renderer installs and every PDF preset self-host the CJK fallback automatically. @file-viewer/assets-standard remains the preferred pre-staged source for the standard profile. If neither source resolves, the installed dependency tree is incomplete and the build fails with an actionable error instead of silently dropping CJK fallback support. pnpm test:pdf-cjk-font-github-242 verifies both the direct ownership and the required copied font/license payload.

The plugin reads the Vite major installed by the application. Vite 5–7 receive build.rollupOptions.output.manualChunks; Vite 8 receives build.rolldownOptions.output.codeSplitting.groups. Existing application groups, priorities, array outputs, and codeSplitting:false are preserved, so the plugin adds only its stable CodeMirror and renderer groups.

Presets

Optional Specialist Renderers

Since 3.1.2, BPMN diagrams and XML validation and transformation profiles are available as explicit opt-ins. Neither is automatically enabled by Full packages.

Adobe design, DICOM, digital-signature inspection, and binary inspection are explicit opt-ins. They are not dependencies of the eight published @file-viewer/*-full packages or the frozen @file-viewer/preset-all compatibility baseline. This preserves the published Full contract and prevents specialist Worker/WASM, medical-imaging, cryptographic, or binary-analysis dependencies from appearing during an ordinary upgrade.

I already use a Full package. How do I enable an optional renderer?

The same rule applies to @file-viewer/web-full, @file-viewer/vue3-full, @file-viewer/vue2.7-full, @file-viewer/vue2.6-full, @file-viewer/react-full, @file-viewer/react-legacy-full, @file-viewer/jquery-full, and @file-viewer/svelte-full.

Keep the Full package installed, then add only the specialist renderer the application needs. The following example enables four specialist renderers; remove any package, import, and array entry that the application does not need:

npm install @file-viewer/renderer-binary @file-viewer/renderer-design @file-viewer/renderer-dicom @file-viewer/renderer-signature

import { binaryRenderer } from '@file-viewer/renderer-binary'
import { designRenderer } from '@file-viewer/renderer-design'
import { dicomRenderer } from '@file-viewer/renderer-dicom'
import { signatureRenderer } from '@file-viewer/renderer-signature'

const options = {
  rendererMode: 'extend',
  renderers: [binaryRenderer, designRenderer, dicomRenderer, signatureRenderer]
}

rendererMode: 'extend' keeps the preset supplied by the Full package and appends these renderers. Use replace only when the explicitly configured renderers should become the complete set.

CLI-managed projects

Run any relevant config add commands, then install the resulting plan:

# Adobe design
npx file-viewer-cli config add psd --write

# DICOM
npx file-viewer-cli config add dicom --write

# Digital-signature containers
npx file-viewer-cli config add p7m --write

# Binary inspection
npx file-viewer-cli config add bin --write

npx file-viewer-cli install --yes

Use npx file-viewer-cli list to inspect the current catalog before changing a project.

Directly installing a Full package and selecting the CLI full profile are intentionally different. A Full package keeps the published preset-all compatibility baseline. The CLI full profile keeps that package and defaults to the established DICOM/signature additions; Adobe design and binary inspection are added only when config add, --formats, or --capabilities explicitly selects them, after their weight and license boundaries are shown.

Using a prebuilt web-full browser bundle?

The downloadable web-full IIFE bundle contains the published Full renderer set. Adobe design, DICOM, digital-signature, and binary-inspector renderers are not embedded in that bundle.

Use a package-manager project or the File Viewer CLI when the integration needs an optional renderer. Copying a renderer package next to the prebuilt bundle does not register it.

The digital-signature renderer can pass safely extracted PDF, XML, image, Office, or other supported content back through the nested-renderer pipeline, so keep the matching normal renderer available when that preview is required. Cryptographic verification does not establish certificate or key trust, qualified-signature status, policy compliance, or legal validity.

Binary inspector boundary

Use the binary inspector only when an application explicitly asks for byte-level inspection. It has no MIME wildcard route and does not replace PNG, ZIP, WASM, or other specialist renderers. The first catalog is read-only and bounded to a 16 MiB whole-file default, 5 seconds of parsing, 512 structure nodes, 16 levels of nesting, and 4 KiB decoded strings; over-limit input fails clearly instead of doing a partial arbitrary scan. A one-shot module Worker parses each input and terminates after a result, error, timeout, or cancellation. The hex grid virtualizes rows, so large accepted inputs do not create one DOM node per byte.

Renderer Package Reference

Install a single renderer when a product needs the smallest possible capability set:

Binary PowerPoint and OpenXML PowerPoint now have separate npm renderer packages. The compatibility aggregate keeps the existing root and subpath APIs. The packaged .ppt 0.3.4 runtime is zero-config in layouts that explicitly install it; for custom asset layouts, configure presentation.pptModuleUrl / pptWorkerUrl / pptWasmUrl / pptFontUrl. PPTX continues to use presentation.workerUrl / workerType.

Strict PPTX-only applications should import pptxRenderer from @file-viewer/renderer-pptx, or configure fileViewerRenderers({ formats: ['pptx'] }). Both paths exclude the classic .ppt package, font, and WASM from the install and production closure. Existing @file-viewer/renderer-presentation/pptx imports remain compatible. The binary-only package is @file-viewer/renderer-ppt.

| @file-viewer/renderer-drawing | drawingRenderer | draw.io, Excalidraw, Mermaid, PlantUML | | @file-viewer/renderer-mindmap | mindmapRenderer | XMind | | @file-viewer/renderer-geo | geoRenderer | GeoJSON, KML, GPX, SHP | | @file-viewer/renderer-typst | typstRenderer | Typst source rendered through local WASM assets | | @file-viewer/renderer-archive | archiveRenderer | Archives and nested file preview | | @file-viewer/renderer-chm | chmRenderer | CHM contents, index, search, internal links, and local Rust/WASM topic extraction | | @file-viewer/renderer-email | emailRenderer | EML, MSG, MBOX | | @file-viewer/renderer-epub | ebookRenderer | EPUB, UMD | | @file-viewer/renderer-text | textRenderer | Markdown, highlighted code, patch, git bundle | | @file-viewer/renderer-image | imageRenderer | Image and HEIC / HEIF paths | | @file-viewer/renderer-media | mediaRenderer | Audio, video, HLS, MIDI summaries | | @file-viewer/renderer-data | dataRenderer | PSD, fonts, SQLite, Parquet, Avro, WASM, WebArchive | | @file-viewer/renderer-eda | edaRenderer | OLB, DRA, GDS, OAS/OASIS |

Engine packages such as @file-viewer/pptx, @file-viewer/geometry-engine, @file-viewer/eda-layout, and @file-viewer/eda-orcad are maintained for renderer internals and advanced reuse. Normal viewer integrations should use the renderer or preset package above.

CHM with a self-hosted Rust/WASM Worker

Install the standalone renderer when an application only needs Compiled HTML Help:

npm install @file-viewer/vue3 @file-viewer/renderer-chm

import { chmRenderer } from '@file-viewer/renderer-chm'

const options = {
  rendererMode: 'replace',
  renderers: [chmRenderer]
}

Vite projects can instead select formats: ['chm'] with copyAssets:true. preset-all and the Full packages already include the renderer, but the deployment must still publish these version-matched files under file-viewer/vendor/chm/:

• chm.worker.js
• chm_wasm.js
• chm_wasm_bg.wasm

The Vite plugin and the same-version asset copy CLI publish that directory automatically. A custom asset layout can override it with options.chm.workerUrl, options.chm.wasmModuleUrl, and options.chm.wasmUrl; do not point production deployments at a public CDN.

The archive is parsed locally in a dedicated Worker. Topic HTML is sanitized before display and rendered in an iframe sandbox without allow-scripts; a restrictive CSP also disables scripts, plugins, forms, base-URL rewriting, and automatically loaded remote active content. Internal ms-its: / mk:@MSITStore links and packaged resources are resolved back into the current CHM instead of receiving network access. This is a read-only documentation viewer, not an ActiveX-compatible HTML Help runtime.

Automatic Preset Assembly

For an Office document platform, the bundler-neutral path is:

npm install @file-viewer/vue3 @file-viewer/preset-office

import officePreset from '@file-viewer/preset-office'

const options = {
  rendererMode: 'replace',
  preset: officePreset
}

@file-viewer/vite-plugin can discover installed presets and inject the generated virtual module into the Vite HTML entry. In Vite projects, add the plugin once and the framework component automatically receives that preview capability without a manual preset import:

npm install -D @file-viewer/vite-plugin

fileViewerRenderers({
  copyAssets: true
  // No preset option required: installed @file-viewer/preset-* packages are discovered.
})

inject defaults to true. Preset packages register themselves in core when imported, and FileViewerOptions.autoRenderers defaults to true in normal extend mode. Set autoRenderers:false only when a product needs full manual control.

The default experience is intentionally zero-config: if the plugin receives no explicit preset, formats, or renderers, or only receives copyAssets:true, it auto-discovers installed @file-viewer/preset-* packages. preset-all takes precedence when present; otherwise installed lite, office, and engineering presets are composed.

Install @file-viewer/preset-all when an application needs the published compatibility baseline. Adobe design, DICOM, digital signatures, and binary inspection remain explicit:

npm install @file-viewer/vue3 @file-viewer/preset-all
# Vite projects add the plugin:
npm install -D @file-viewer/vite-plugin

Use preset:'auto' or autoPresets:true when you also enable scan:true; this keeps installed preset discovery active while source hints add extra renderers. If preset-all is installed, it takes precedence to avoid importing narrower presets twice.

fileViewerRenderers({
  preset: 'auto',
  scan: true,
  formats: ['pdf'],
  copyAssets: true,
  chunkStrategy: 'renderer'
})

Manual Control

Strict bundles can still use the virtual module directly:

fileViewerRenderers({
  formats: ['pdf'],
  inject: false,
  copyAssets: true
})

import { configuredFileViewerRenderers } from 'virtual:file-viewer-renderers'

const options = {
  rendererMode: 'replace',
  renderers: configuredFileViewerRenderers
}

scan:true detects hints such as fileViewerFormats, data-file-viewer-formats, and upload accept attributes, then merges them with explicit formats.

Missing Renderer Guidance

If a file extension is in the supported matrix but its renderer has not been assembled, the viewer shows a friendly install-oriented state. For example, opening .pdf without the PDF renderer recommends @file-viewer/preset-office or @file-viewer/renderer-pdf. Only extensions outside the matrix are shown as truly unsupported.

Asset Rules

Use copyAssets:true or npx --yes file-viewer-copy-assets ./public/file-viewer for standard-package offline deployments. Full packages include the matching CLI and use npx --no-install file-viewer-copy-assets ./public/file-viewer. Worker, WASM, font, PDF, CAD, Typst, Archive, CHM, Data, and Draw.io assets should be served from your own domain. A CHM deployment is complete only when vendor/chm/chm.worker.js, vendor/chm/chm_wasm.js, and vendor/chm/chm_wasm_bg.wasm are available with JavaScript and WebAssembly MIME types.

CHM Completion Checklist

• @file-viewer/renderer-chm is available as a standalone renderer and is included by preset-all / Full packages.
• The Rust/WASM parser runs in a dedicated Worker, and standard asset tooling self-hosts the Worker, JavaScript bridge, and WASM binary under vendor/chm/.
• Contents, keyword index, text search, internal navigation, and packaged resources stay within the current archive.
• Topic documents are sanitized, scripts remain disabled by sandbox and CSP, and remote active content is not loaded automatically.

Optional IFC BIM viewer

The explicit @file-viewer/renderer-3d/ifc entry enhances only IFC files with local That Open / Web-IFC visualization, selection, properties and a configuration hook. Existing Full/Office entry points remain unchanged. Install the optional peers and self-host their matching Worker/WASM assets with file-viewer-ifc-assets. The exact setup and licensing notes are in the package's IFC guide.