diff --git a/Document-Processing-toc.html b/Document-Processing-toc.html
index 7816b464a..ab65c6e35 100644
--- a/Document-Processing-toc.html
+++ b/Document-Processing-toc.html
@@ -991,6 +991,17 @@
 									<li><a href="/document-processing/pdf/pdf-viewer/react/getting-started-with-server-backed">with Server-Backed PDF Viewer</a></li>
 								</ul>
 							</li>
+							<li>Architecture
+								<ul>
+									<li><a href="/document-processing/pdf/pdf-viewer/react/architecture/architecture-pdfviewer">Architecture</a></li>
+									<li><a href="/document-processing/pdf/pdf-viewer/react/architecture/how-pdf-rendering-works-in-browser">How PDF Rendering Works in the Browser</a></li>
+									<li><a href="/document-processing/pdf/pdf-viewer/react/architecture/standalone-vs-server-backed-pdf-viewer">Standalone vs Server-Backed Viewer</a></li>
+									<li><a href="/document-processing/pdf/pdf-viewer/react/architecture/when-backend-pdf-services-are-required">When Backend PDF Services Are Required</a></li>
+									<li><a href="/document-processing/pdf/pdf-viewer/react/architecture/performance-model-for-large-pdfs">Performance Model for Large PDFs</a></li>
+									<li><a href="/document-processing/pdf/pdf-viewer/react/architecture/self-hosted-on-prem-deployment">Self-Hosted and On-Prem Deployment</a></li>
+									<li><a href="/document-processing/pdf/pdf-viewer/react/architecture/pdf-standards-conformance">Supported PDF Standards and Conformance</a></li>
+								</ul>	
+							</li>	
 							<li>
 								Environment Integration
 								<ul>
diff --git a/Document-Processing/PDF/PDF-Viewer/react/architecture/architecture-pdfviewer.md b/Document-Processing/PDF/PDF-Viewer/react/architecture/architecture-pdfviewer.md
new file mode 100644
index 000000000..e4f6c07ed
--- /dev/null
+++ b/Document-Processing/PDF/PDF-Viewer/react/architecture/architecture-pdfviewer.md
@@ -0,0 +1,251 @@
+---
+layout: post
+title: Architecture of Syncfusion React PDF Viewer | Syncfusion
+description: High-level design, rendering pipeline, data flow, and performance considerations of the Syncfusion React PDF Viewer.
+platform: document-processing
+control: PDF Viewer
+documentation: ug
+---
+
+# Architecture of Syncfusion React PDF Viewer
+
+This guide provides a deep dive into the technical design and internal workings of the Syncfusion React PDF Viewer, including its high-level component architecture, rendering pipeline, data flow across the client and server boundaries, and performance optimization strategies. Understanding these concepts will help you make informed decisions about customization, feature integration, and troubleshooting.
+
+## Overview
+
+The Syncfusion React PDF Viewer operates on a **hybrid client-server architecture** designed for scalability, performance, and rich interactivity:
+
+- **Client-side layer**: A responsive React component that handles user interaction, rendering, annotations, and form filling directly in the browser using the PDFium-based rendering engine. The client provides a smooth, zero-latency user experience for common operations like navigation, zooming, and markup.
+- **Server-side layer**: Optional back-end services (via `serviceUrl`) that enable advanced features such as document preprocessing, OCR, form field recognition, digital signatures, secure document streaming, and import/export operations using the Syncfusion PDF Library.
+
+This architecture allows you to use the viewer in a **client-only mode** (perfect for lightweight applications) or with **full server integration** (for enterprise scenarios requiring advanced document processing, security, and compliance).
+
+This page explains the internal architecture of the viewer, focusing on how major modules collaborate, how documents are parsed and rendered using PDFium, and how data flows across threads and network boundaries. This content is intended for developers and integrators who want to understand the viewer's internal design to make informed decisions about customization, performance tuning, and advanced integrations.
+
+**Key Technology Stack:**
+- **PDFium**: Google's open-source PDF rendering and manipulation engine used for fast, reliable PDF parsing and rasterization on the client.
+- **Syncfusion PDF Library**: Server-side library for advanced document processing, preprocessing, and export operations.
+
+## High-level components
+
+The React PDF Viewer is built as a set of modular components, each responsible for a specific responsibility in the viewing pipeline. The following diagram illustrates how these components interact:
+
+![High-level Component Architecture](../images/high-level-components.png)
+
+- **UI Shell** – Provides the container layout, dialogs, panels, and responsive structure. Manages the overall layout and ensures the viewer adapts responsively across different screen sizes and devices.
+
+- **Viewer Core** – Coordinates viewer state, document life-cycle, and event routing. Acts as the central orchestrator that manages document loading, page navigation, state synchronization, and event propagation across all modules.
+
+- **Rendering Engine** – Powered by PDFium, converts parsed PDF page data into visual output using canvas and SVG layers. Handles rasterization, text extraction, and visual rendering of PDF content with high fidelity.
+
+- **Worker(s)** – Perform CPU‑intensive tasks such as document parsing, font processing, and page rasterization outside the main thread. This off-thread processing ensures a responsive UI during heavy operations.
+
+- **Toolbar** – Exposes user actions such as navigation, zooming, annotation tools, printing, and download. 
+
+See [Toolbar Integration](../toolbar-customization/overview) for customization options and available tools.
+
+- **Thumbnail and Bookmark panels** – Enable page navigation and structural browsing. Allow users to quickly jump between pages and view document structure hierarchically. 
+
+See [Thumbnail Page](../navigation#thumbnail-navigation) and [Bookmark Page](../navigation#bookmark-navigation) for page navigation.
+
+- **Annotation and Forms modules** – Manage interactive PDF elements and forms. Interactive elements are indexed and maintained separately for efficient manipulation and serialization.
+
+See [Annotations](../annotation/overview) and [Working with Form Fields](../forms/overview) for detailed usage and API reference.
+
+- **Injected Services** – Enable optional features such as text search, magnification, printing, and form filling. These services are plugged into the viewer architecture based on your licensing and configuration.
+
+See [Text Search](../text-search), [Magnification](../magnification), [Printing](../print/overview) to explore more features.
+
+## Document parsing & internal data model
+
+When a PDF document is loaded, the PDFium rendering engine parses it into a structured internal data model that represents pages, content streams, fonts, images, annotations, form fields, and metadata. This model acts as the foundation for all rendering and interaction workflows in the viewer.
+
+**Key aspects of the data model:**
+
+- **Page representation**: Each page is decomposed into individual drawing commands, text blocks, images, and vector graphics.
+- **Font and resource management**: Fonts are extracted and processed; embedded and external fonts are handled gracefully.
+- **Annotation and form field tracking**: Interactive elements are indexed and maintained separately for efficient manipulation and serialization.
+- **Resource caching**: Parsed page resources are cached to minimize repeated processing during page navigation and zoom operations, improving responsiveness.
+
+For very large or complex documents, memory usage can increase significantly. In such cases, consider implementing **partial loading strategies** or streaming approaches via the server back-end. See [Performance Optimization](../getting-started-overview) for best practices.
+
+## Worker model / Off-main-thread processing
+
+The viewer uses **Web Workers** to offload resource‑intensive operations such as document parsing, font processing, and page rasterization from the main UI thread. This architecture ensures smooth user interaction, responsive scrolling, and prevents UI blocking during heavy computations.
+
+**How the worker model operates:**
+
+1. The main thread (React component) receives user actions and coordinates document loading.
+2. Work items (e.g., "parse page 5", "rasterize at 150% zoom") are serialized and sent to worker threads via `postMessage()`.
+3. Workers execute PDFium rendering commands and message back rendering results (image data, text layers).
+4. The main thread receives results and updates the DOM with new rendered content.
+
+When workers are unavailable or disabled, the viewer gracefully falls back to main‑thread execution with reduced performance. This fallback is useful for debugging or in restricted environments.
+
+![Worker Message Flow and Coordination](../images/worker-message-flow.png)
+
+## Network & serviceUrl interactions
+
+The React PDF Viewer supports both **standalone client-side** and **client-server hybrid** architectures:
+
+### Client-only mode (no server)
+- Use the [`documentPath`](https://ej2.syncfusion.com/react/documentation/api/pdfviewer/index-default#documentpath) property to load PDF files directly from your web server or CDN.
+- All rendering, annotations, and form filling happen entirely on the client using PDFium.
+- No network latency for viewing operations; ideal for lightweight, offline-friendly applications.
+
+### Client-server mode (with serviceUrl)
+- The [`serviceUrl`](https://ej2.syncfusion.com/react/documentation/api/pdfviewer/index-default#serviceurl) property enables server‑backed features such as advanced document processing, OCR, streaming, and import/export operations using the Syncfusion PDF Library.
+- Documents may be streamed incrementally (useful for large files) or fetched fully before rendering, depending on your configuration.
+- Server-side preprocessing can optimize documents before delivering them to clients.
+
+**Authentication and security:**
+
+Authentication headers can be injected for secured endpoints or cloud storage integrations:
+
+```js
+ajaxRequestSettings: {
+  headers: {
+    Authorization: 'Bearer <access-token>'
+  }
+}
+```
+See How to add [custom headers in AjaxRequestSettings](https://help.syncfusion.com/document-processing/pdf/pdf-viewer/react/how-to/add-header-value)
+
+**Common integration challenges:**
+- CORS restrictions when loading PDFs from different origins
+- Invalid or unreachable `serviceUrl` endpoints
+- Expired authentication tokens during long viewing sessions
+- Network timeouts on slow connections
+
+See [Server Integration](../getting-started-with-server-backed) for detailed configuration guidance and [Troubleshooting](../troubleshooting/troubleshooting) for common issues.
+
+## Annotation & forms architecture
+
+Annotations and form fields are core interactive elements of the PDF viewing experience. The viewer maintains a sophisticated layer-based rendering model to manage these elements efficiently.
+
+**Annotation rendering and management:**
+
+Annotations (highlights, underlines, strikethrough, freehand drawings, shapes, stamps, ink, and text markup) are rendered as dedicated interactive layers that sit above the base PDF content. This layering approach ensures:
+
+- **Non-destructive markup**: Annotations overlay the original PDF without modifying the underlying document.
+- **Efficient rendering**: Only annotation layers update when user marks up the document; PDF content remains static.
+- **Event propagation**: User interactions with annotations generate events that flow through the Viewer Core.
+- **Persistence and serialization**: Annotation data can be exported to XFDF, JSON, or other formats for storage and reimporting across sessions.
+
+See [Annotations in React PDF Viewer](../annotation/overview) for comprehensive annotation types, styling, and API usage.
+
+**Form field handling:**
+
+Form fields (text inputs, checkboxes, radio buttons, dropdowns, signature fields) are parsed from the PDF and maintained in memory with:
+
+- **Visual representation**: Each field is rendered with its defined appearance (fonts, colors, borders).
+- **Behavioral properties**: Validation rules, calculations, and interdependencies are tracked.
+- **Event binding**: User input to form fields triggers validation, calculation, and change events.
+- **State management**: Field values are synchronized across the document model and UI.
+
+Advanced form features include:
+
+- **Digital signatures**: Sign form fields with certificates; signature validation and time-stamping via server integration.
+- **Form validation**: Custom validation rules and required field enforcement.
+- **Form submission**: Export form data as FDF, XFDF, or JSON formats.
+- **Form locking**: Prevent field editing after submission for read-only workflows.
+
+See [Working with Form Fields](../forms/overview) and [Digital Signatures](../digital-signature/add-digital-signature-react) for detailed examples and API documentation.
+
+**Data serialization workflows:**
+
+The viewer supports multiple serialization formats for annotation and form data:
+
+- **XFDF (XML Forms Data Format)**: Industry-standard format for portable annotation and form data.
+- **JSON**: Lightweight, programmatic format for custom integrations.
+- **FDF (Forms Data Format)**: Legacy format supported for backward compatibility.
+
+This enables workflows where annotation and form data can be:
+- Exported from the viewer and processed server-side (e.g., archiving, printing with annotations, compliance reporting).
+- Imported from external sources and merged into new PDFs.
+- Synchronized across multiple viewers or applications.
+
+See Export and Import Annotation for [Annotation](../annotation/export-import/export-annotation) and [Forms](../forms/import-export-form-fields/export-form-fields)
+
+## Accessibility & event flow
+
+The React PDF Viewer is designed with accessibility as a first-class concern, ensuring that all users—including those with visual, motor, and cognitive disabilities—can interact with PDF documents effectively.
+
+**Accessibility features:**
+
+- **Semantic markup and ARIA roles**: The viewer uses proper HTML semantics (`<nav>`, `<button>`, `<article>`) and ARIA attributes (`aria-label`, `aria-live`, `role`) to communicate structure and purpose to assistive technologies.
+- **Keyboard navigation**: All viewer functions are accessible via keyboard. Users can navigate pages, activate tools, fill forms, and create annotations without a mouse.
+- **Screen reader support**: Document structure, page information, form labels, and annotation content are announced clearly to screen readers.
+- **Focus management**: Focus is programmatically managed to guide users through interactive workflows (e.g., form filling).
+- **Color contrast**: UI elements meet WCAG 2.1 AA color contrast standards.
+- **Text extraction**: PDF text is properly extracted and made available for copying, searching, and screen reader consumption.
+
+**Event flow architecture:**
+
+Events generated by user interactions flow through a well-defined event system:
+
+1. **Input events**: Mouse clicks, touch gestures, keyboard input, and resize events are captured.
+2. **Viewer Core processing**: Events are dispatched to the appropriate module (Toolbar, Annotation, Forms, etc.).
+3. **Module handling**: Each module processes the event according to its logic (e.g., Forms module validates input).
+4. **Event propagation**: Modules emit higher-level events (e.g., `onAnnotationAdd`, `onFormFieldChanged`) that applications can listen to.
+
+This design ensures that custom event handlers integrate seamlessly with the viewer's architecture.
+
+See [Keyboard Shortcuts](../keyboard-accessibility) and [Accessibility Guidelines](../accessibility) for best practices when embedding the viewer in accessible applications.
+
+## Theming & styling
+
+The React PDF Viewer applies themes (Material 3, Material Design, etc.) and CSS styling through a cascading layer system. Understanding the recommended import order and safe style override patterns is essential to maintain consistent theming and prevent unintended side effects.
+
+**Recommended theme import order:**
+
+Import theme stylesheets **before** component-specific styles to ensure correct cascade priority and avoid style conflicts:
+
+```js
+// ✓ Correct order
+import '@syncfusion/ej2-base/styles/material.css';           // Theme
+import '@syncfusion/ej2-pdfviewer/styles/pdfviewer.css';    // Component styles
+```
+
+**Available themes:**
+
+- **Material Design**: Follows Material Design 2 guidelines with clean, familiar components.
+- **Material Design 3**: Modern Material Design 3 with updated colors, typography, and motion.
+- **Light and Dark modes**: Automatic or manual switching between light and dark color schemes.
+- **Bootstrap**: Bootstrap 5 theme compatibility.
+- **Custom themes**: Define your own color palettes and typography by overriding CSS variables.
+
+**Safe style overriding:**
+
+Custom styling can be safely applied using exposed CSS custom properties (variables) without modifying component internals or affecting viewer layout and interaction behavior. This approach isolates custom styles and makes them resilient to component updates:
+
+```css
+/* Override theme variables safely */
+:root {
+  --pdfviewer-primary-color: #1976d2;
+  --pdfviewer-text-color: #333333;
+  --pdfviewer-border-radius: 4px;
+}
+```
+
+**Best practices:**
+
+1. Always import theme before component styles to establish correct CSS cascade.
+2. Use CSS custom properties (variables) to customize colors, spacing, and typography.
+3. Avoid inline style modifications to component DOM elements; use CSS classes instead.
+4. Test theme changes across all viewer features (Toolbar, panels, dialogs, annotations).
+
+For comprehensive theme customization options, CSS variable reference, and available themes, see [Theming Guide](../theming-and-styling) and [CSS Class Reference](../theming-and-styling#supported-themes).
+
+## Related architecture and integration topics
+
+- [Getting Started with React PDF Viewer](../getting-started) – Quick setup and your first PDF viewer.
+- [Loading PDF Documents](../open-pdf-files) – Detailed guide on document sources, streaming, and error handling.
+- [Toolbar Integration and Customization](../toolbar-customization/overview) – Customize toolbar buttons and actions.
+- [Annotations in React PDF Viewer](../annotation/overview) – Complete reference for annotation types, styling, and API.
+- [Working with Form Fields](../forms/overview) – Form field rendering, validation, and submission workflows.
+- [Digital Signatures](../digital-signature/add-digital-signature-react) – Signing PDFs and validating signatures.
+- [Accessibility Guidelines](../accessibility) – Keyboard shortcuts, screen reader support, and best practices.
+- [Server Integration](../getting-started-with-server-backed) – Using `serviceUrl` for advanced preprocessing and export operations.
+- [Troubleshooting Common Issues](../troubleshooting/troubleshooting) – CORS, authentication, rendering, and worker problems.
+- [Syncfusion PDF Library Documentation]() – Server-side PDF processing and manipulation reference.
\ No newline at end of file
diff --git a/Document-Processing/PDF/PDF-Viewer/react/architecture/how-pdf-rendering-works-in-browser.md b/Document-Processing/PDF/PDF-Viewer/react/architecture/how-pdf-rendering-works-in-browser.md
new file mode 100644
index 000000000..325d5835c
--- /dev/null
+++ b/Document-Processing/PDF/PDF-Viewer/react/architecture/how-pdf-rendering-works-in-browser.md
@@ -0,0 +1,591 @@
+---
+layout: post
+title: How PDF Rendering Works in the Browser  | Syncfusion
+description: Understand how PDF files are parsed, processed, and rendered as pixels in the browser, and the performance and security considerations involved.
+platform: document-processing
+control: PDF Viewer
+documentation: ug
+---
+
+# How PDF Rendering Works in the Browser
+
+A detailed walkthrough of the end-to-end PDF rendering pipeline in the browser. Learn how PDFium and the Syncfusion React PDF Viewer parse PDF documents, resolve resources, convert drawing instructions into pixels, and handle the practical trade-offs that affect performance, accuracy, and security.
+
+## Overview
+
+Rendering a PDF in the browser is a multi-stage process that transforms a binary PDF file into interactive visual content on screen. Understanding this pipeline is essential for developers and integrators who need to:
+
+- **Troubleshoot rendering issues** – Identify which stage of the pipeline is causing problems (e.g., missing images, blurry text, font misalignment).
+- **Optimize performance** – Apply targeted caching, lazy-loading, and worker strategies to improve rendering speed and responsiveness.
+- **Make informed architectural decisions** – Choose between client-side rendering, server preprocessing, or hybrid approaches based on document complexity and user experience requirements.
+- **Ensure security and compliance** – Understand cross-origin resource sharing (CORS), font handling, and memory constraints.
+
+This page explains the conceptual rendering pipeline used by the Syncfusion React PDF Viewer (powered by the PDFium rendering engine). While the specific implementation details may vary, the core concepts apply to most browser-based PDF viewers.
+
+## 1. Parsing and decoding
+
+PDF rendering begins with parsing the binary PDF file structure. The PDFium rendering engine extracts:
+
+- **Document structure**: Indirect objects, cross-reference tables, and content streams that define each page.
+- **Page hierarchy**: Resolving object references to reconstruct complete page definitions.
+- **Resources**: Associated fonts, images, graphics states, and annotations linked to each page.
+
+**Resource extraction:**
+
+Once pages are identified, the viewer extracts encoded content:
+
+- **Image streams**: Embedded images (JPEG, PNG, TIFF, etc.) are identified but **not decoded until rendering time** to minimize memory usage.
+- **Font streams**: Embedded font data is identified; subset and full fonts are handled separately.
+- **Content streams**: PDF drawing commands (path operators, text placement, fills) are extracted for later conversion to a display list.
+
+**Parsing location (main thread vs. worker):**
+
+Parsing is typically **offloaded to a Web Worker** to prevent blocking the UI thread. This is especially important for large PDFs where parsing can take hundreds of milliseconds. The main thread coordinates by sending parsing work items to the worker via `postMessage()`. If workers are unavailable, the viewer falls back to main-thread parsing with reduced responsiveness.
+
+**Performance tip:** For large documents, consider **server-side document preprocessing** using the Syncfusion PDF Library to simplify structure, reduce object count, and speed up parsing on the client. See [Server Integration](#) for details.
+
+## 2. Resolve resources (fonts, images)
+
+After parsing, the viewer resolves and fetches resources needed for rendering.
+
+**Font resolution:**
+
+- **Embedded fonts**: Full or subset fonts stored in the PDF are extracted and made available to the rendering engine.
+- **System fonts**: If a PDF references standard fonts (e.g., Helvetica, Times New Roman) not embedded, the viewer uses system fonts.
+- **Font subsetting trade-off**: Subset fonts reduce PDF file size but require careful glyph-to-character mapping during text layer creation (see [HTML Text Layer](#5-html-text-layer-selectable-and-searchable-text)). If mapping fails, text selection becomes misaligned.
+
+**Image resolution:**
+
+- **Decoding**: Encoded image streams (JPEG, PNG, TIFF, Flate-compressed) are identified and decoded **on-demand** during rendering, not during resource resolution. This lazy approach saves memory for documents with many images.
+- **Format handling**: Common formats are supported natively by canvas/WebGL; unsupported formats are trans-coded server-side via `serviceUrl`.
+
+**Cross-origin resource sharing (CORS):**
+
+If fonts or images reference external URLs (uncommon but possible), CORS headers must permit browser access. Missing or mis-configured CORS headers cause resource load failures. Configure your server:
+
+```
+Access-Control-Allow-Origin: https://your-app-domain
+```
+
+**Caching strategies:**
+
+Effective resource caching dramatically improves performance for multi-page documents:
+
+- **Decoded resource cache**: Fonts and images are cached in memory after first decode to avoid redundant processing during page re-renders and zooms.
+- **Cache eviction**: For large PDFs on memory-constrained devices, implement cache eviction policies to free resources for unseen pages.
+- **HTTP caching**: Serve PDFs and resources with appropriate `Cache-Control` headers to enable browser caching.
+
+**Performance tip:** For documents with large or many images, consider **server-side image optimization** (compression, trans-coding) before serving to clients.
+
+## 3. Convert PDF drawing instructions into an internal display list
+
+PDF content streams contain drawing instructions that define how to render page content. The viewer converts these instructions into an internal **display list** (also called a **scene graph**), which serves as an optimized intermediate representation for efficient rendering.
+
+**How it works:**
+
+PDFium processes the raw PDF drawing commands and converts them into an optimized internal format that includes:
+
+- Resolved graphics operations (paths, fills, images, text) with final coordinates and properties
+- Transformed graphics state changes (color, scaling, transparency)
+- Bounding boxes for efficient region management
+
+**Performance benefits:**
+
+1. **Efficient re-rendering**: Zooming, panning, or rotating reuses the display list; no need to re-parse the original instructions
+2. **Partial updates**: Only changed regions (e.g., annotation overlays) are re-rendered; unchanged content is cached
+3. **Memory efficiency**: The optimized display list is typically smaller than the original PDF content stream
+4. **Reliability**: Rendering errors are caught early, ensuring consistent results
+
+**Trade-offs:**
+
+- **Memory usage**: Complex pages consume more memory for the display list; very large pages may require tiling strategies
+- **Conversion time**: Initial display list creation adds latency, though this is typically handled off-thread (see [Off-main-thread processing](#7-off-main-thread-processing-workers--wasm))
+
+## 4. Rendering (Rasterization / Vector rendering / Compositing)
+
+The display list is converted to visual output on screen through a rendering process that handles multiple rendering targets, scaling, anti-aliasing, and layer composition.
+
+**Rendering back-ends:**
+
+The viewer can use different rendering back-ends depending on platform and performance requirements:
+
+- **Canvas 2D**: Most common; rasterize display list to a bitmap on an HTML5 `<canvas>` element. Hardware-accelerated on most devices.
+- **SVG**: Vector rendering for specific use cases (e.g., accessibility, search ability). Slower for complex pages but produces sharp text and graphics.
+- **WebGL**: High-performance GPU-accelerated rasterization for large documents or repeated re-renders (zooming, panning).
+
+**Device pixel ratio (DPR) scaling:**
+
+To render sharp content on high-DPI displays (e.g., 2x or 3x scaling on mobile), the viewer:
+
+1. Reads `window.devicePixelRatio` (e.g., 2.0 for Retina displays).
+2. Allocates canvas buffer at `canvas.width = logicalWidth × DPR` to capture physical pixels.
+3. Applies CSS scaling to display the buffer at logical size.
+
+**Blurry output** is typically caused by DPR mismatch. See [Common issues & quick troubleshooting](../troubleshooting/troubleshooting).
+
+**Anti-aliasing and quality:**
+
+PDFium applies sub-pixel anti-aliasing to smooth edges of text and graphics. Quality can be tuned via rendering parameters:
+
+- **Quality levels**: Faster (less sampling) vs. higher quality (more sampling and processing).
+- **Font hinting**: Can improve text clarity for small fonts.
+
+**Layer composition:**
+
+Multiple layers are composited to create the final output:
+
+1. **Base layer (PDF content)**: Rasterize once and cached.
+2. **Annotation layer**: Overlaid above PDF content; updated when annotations change.
+3. **Text layer**: Positioned HTML elements for selection/search (see section 5); rendered with `pointer-events: none` to allow clicks through to underlying layers.
+4. **UI layer**: Toolbar, dialogs, form highlights.
+
+This layering ensures efficient updates: only modified layers are re-rendered.
+
+**Performance considerations:**
+
+- Rendering large pages or high DPR values increases memory and CPU usage.
+- Repeated renders (e.g., continuous zooming) benefit from caching strategies (see section 8).
+
+## 5. HTML text layer (selectable and searchable text)
+
+To enable text selection, copy-paste, and search functionality, the viewer constructs an **invisible HTML text layer** that overlays the rendered PDF content. This layer bridges the gap between PDF rendering and DOM-based text interaction.
+
+**How the text layer works:**
+
+1. **Extract glyph information**: During PDF parsing, the viewer extracts text content, glyph IDs, and positioning matrices from the PDF content stream.
+2. **Render invisible HTML elements**: For each text span, an HTML element (typically a `<span>`) is positioned and sized to match the glyph positions in the rendered PDF.
+3. **Apply CSS styling**: Text elements are styled with `opacity: 0` or positioned absolutely so they're invisible but interactive.
+4. **Enable interaction**: When users select or search text, they interact with the HTML layer, which references the underlying PDF text.
+
+```html
+<!-- Example: invisible text layer overlay -->
+<div class="pdfviewer-text-layer">
+  <span style="position: absolute; left: 50px; top: 100px; width: 40px; height: 15px;">Hello</span>
+  <span style="position: absolute; left: 95px; top: 100px; width: 30px; height: 15px;">World</span>
+</div>
+```
+
+**Challenges in text layer creation:**
+
+- **Ligatures**: Some fonts replace character sequences (e.g., "fi") with single glyphs. Mapping glyphs back to characters requires special handling.
+- **Glyph-to-character mapping**: Subset fonts include only glyphs used in the document. Determining which Unicode characters correspond to subset glyph IDs is complex and error-prone.
+- **Font substitution**: If the PDF references fonts unavailable in the browser, fallback fonts are used. If fallback fonts have different metrics, text positioning becomes misaligned.
+- **Vertical text**: Right-to-left scripts (Arabic, Hebrew) and vertical text (CJK languages) require special handling.
+
+**Text selection misalignment:**
+
+If text layer elements don't align with rendered text, the root cause is usually:
+
+- **Font metric mismatch**: Embedded font and fallback font have different character widths.
+- **Subset mapping error**: Incorrect glyph-to-character mapping, causing shifted text positions.
+- **Rotation/scaling**: Transform matrices not correctly applied during positioning.
+
+See [Common issues & quick troubleshooting](../troubleshooting/troubleshooting) for diagnosis and fixes.
+
+N> **Performance tip:** Text layer creation is typically offloaded to a worker thread to avoid UI blocking. For documents with very large text volumes, consider lazy text layer creation (only for visible pages).
+
+## 6. Fonts: embedding, subsetting, and fallback
+
+Font handling is a critical and often overlooked aspect of PDF rendering. PDFs can reference fonts in multiple ways, each with different implications for rendering quality and text layer accuracy.
+
+**Font types and embedding:**
+
+- **Fully embedded fonts**: The PDF includes the entire font data. The viewer uses these directly; rendering is accurate and text selection is reliable. Common in documents created with office applications.
+- **Subset fonts**: Only glyphs used in the document are embedded, reducing PDF size. This saves bandwidth but complicates text layer creation (see section 5).
+- **Referenced fonts**: The PDF references standard fonts (e.g., "Helvetica", "Times New Roman") by name without embedding data. The viewer must find these on the system or use fallback fonts.
+- **Type 3 fonts**: Custom fonts defined by drawing operations. Rendering is correct, but text layer creation is impossible (text selection won't work).
+
+**Subsetting trade-offs:**
+
+| Aspect | Fully embedded | Subset |
+|--------|---|---|
+| PDF size | Larger | Smaller |
+| Rendering quality | Excellent | Excellent |
+| Text selection reliability | High | Lower (mapping errors common) |
+| Copy-paste accuracy | High | Lower |
+| Search functionality | Reliable | Prone to errors |
+
+**System font fallback:**
+
+When the viewer encounters a referenced font not available in the browser:
+
+1. Check system font directories for a matching font name.
+2. If no match, use a generic fallback (serif, sans-serif, monospace).
+3. Apply metric adjustments (spacing, size) to approximate the original font's appearance.
+
+**Font rendering quality vs. text layer accuracy:**
+
+- Embedded fonts render correctly but may introduce text layer mapping errors (subset fonts especially).
+- System fonts render with fallback fonts but may look visibly different. However, text layer is often more reliable because character-to-glyph mapping is straightforward.
+
+**Best practices and troubleshooting:**
+
+1. **Preload system fonts**: If your PDFs reference common fonts, preload them in your HTML:
+   ```html
+   <link rel="preload" href="/fonts/Helvetica.woff2" as="font">
+   ```
+
+2. **Validate glyph coverage**: Before using a fallback font, verify it covers all glyphs in the PDF. Missing glyphs will render as boxes or boxes.
+
+3. **CORS configuration**: If fonts are served from a different origin, ensure CORS headers permit access:
+   ```
+   Access-Control-Allow-Origin: *
+   ```
+
+4. **Server-side font optimization**: Use the Syncfusion PDF Library to pre-process PDFs and convert subset fonts to fully embedded fonts, improving text layer reliability. See [Server Integration](#).
+
+5. **Font substitution tables**: Some viewers allow configuring font substitution mappings (e.g., "Helvetica" → "Arial") to improve visual consistency across platforms.
+
+**Common font issues:**
+
+- **Missing glyphs** (rendered as boxes): Fallback font lacks glyphs present in the original font.
+- **Text layout errors**: Metric mismatch between embedded and fallback fonts causes misalignment.
+- **Type 3 font failure**: Text selection is disabled; consider server-side conversion to standard fonts.
+
+## 7. Off-main-thread processing (Workers / WASM)
+
+PDF rendering involves CPU-intensive tasks (parsing, font processing, rasterization) that can block the main thread and freeze the UI. The Syncfusion React PDF Viewer solves this by offloading heavy work to background threads.
+
+**Worker-based architecture:**
+
+The viewer uses **Web Workers**—background threads that run JavaScript in parallel with the main thread without blocking UI interactions:
+
+1. **Task dispatch**: The main thread sends work items (e.g., "parse page 5") to workers via `postMessage()`.
+2. **Off-thread execution**: Workers execute PDFium parsing, decoding, and rasterization commands.
+3. **Result callback**: Workers send rendered results (bitmap data, text layer, etc.) back to the main thread.
+4. **DOM update**: The main thread receives results and updates the DOM with new rendered content.
+
+**Example message flow:**
+
+```
+Main Thread:
+  → "Parse and render page 5, 100dpi"
+     ↓
+Worker Thread:
+  → Execute PDFium rendering commands
+  → Generate bitmap and text layer data
+     ↓
+  ← { image: ImageData, textLayer: Array }
+     ↓
+Main Thread:
+  → Update canvas and text layer DOM
+```
+
+**Worker pool and concurrency:**
+
+- **Multiple workers**: The viewer typically creates a pool of workers (e.g., 2-4) to parallelize work. Page 5 can be rendered while page 6 is being parsed.
+- **Queue management**: If work exceeds available workers, tasks are queued and processed in order.
+- **Configurable pool size**: Tune worker count based on device CPU cores and available memory.
+
+**WebAssembly (WASM) acceleration:**
+
+PDFium itself is implemented in C++ and compiled to WebAssembly for faster execution than equivalent JavaScript. This enables:
+
+- Fast PDF parsing
+- Efficient rasterization (rendering)
+- Reduced memory overhead
+
+**Graceful fallback:**
+
+If workers are unavailable (disabled by user, unsupported browser, or restricted environment):
+
+- Parsing and rasterization execute on the main thread.
+- UI responsiveness decreases; long operations may freeze the page.
+- Fallback mode is useful for debugging but should not be used in production.
+
+**Configuration and troubleshooting:**
+
+- **Worker count**: Adjust `workerCount` in viewer config to balance parallelism and memory usage.
+- **Worker path**: Ensure worker scripts are served from the correct location and accessible.
+- **Security**: Workers must be served from the same origin (same domain and protocol) due to browser security policies.
+
+**Performance impact:**
+
+- **Positive**: Off-thread processing keeps the main thread responsive, enabling smooth UI interactions during rendering.
+- **Trade-off**: Message passing overhead (serializing data) adds latency for very small tasks; not all operations benefit from worker offloading.
+
+## 8. Device & performance considerations
+
+Rendering performance varies dramatically based on device capability (CPU, memory, GPU), document complexity (number of pages, image density, font count), and network conditions. Strategic optimizations can dramatically improve user experience, especially on low-powered devices and over slow networks.
+
+**Core performance optimization strategies:**
+
+### DPR-aware rendering
+
+High-DPI displays (phones, tablets, modern laptops) have `devicePixelRatio > 1`, requiring higher-resolution rendering. Without proper scaling, output is blurry. Proper handling:
+
+- Allocate canvas buffer at `physicalWidth = logicalWidth × devicePixelRatio`
+- Apply CSS scaling to display at logical size
+- Monitor DPR changes (orientation changes, moving window between displays)
+
+### Lazy page rendering (visible-only rendering)
+
+Load and render only pages currently visible to the user:
+
+- **Virtual scrolling**: Maintain a viewport; render pages entering the viewport, unload pages leaving it.
+- **Memory savings**: For 500-page documents, render only 3-5 visible pages instead of all 500.
+- **Network savings**: Fetch resources (fonts, images) only for visible pages.
+
+Implementation requires a scroll listener and dynamic page allocation.
+
+### Thumbnail prefetching
+
+While the user views page 10, prefetch thumbnails for nearby pages (9, 11, 12):
+
+- Improves perceived responsiveness when navigating quickly.
+- Use lower DPR and compression for thumbnails to minimize memory.
+
+### Resource caching and eviction
+
+- **Cache decoded images**: Store decoded images in memory; reuse during zoom operations.
+- **Cache rasterized pages**: For fixed zoom levels, cache rendered bitmaps to avoid re-rendering on scroll.
+- **Cache fonts**: Decoded fonts are reused across pages; large PDFs benefit significantly.
+- **Eviction policy**: Implement LRU (least-recently-used) or other policies to free cache when memory approaches limits.
+
+### Minimize zoom re-renders
+
+Continuous zoom events (mouse wheel, pinch) can trigger re-renders for each intermediate level:
+
+- **Debounce zoom**: Wait for zoom gestures to complete before rendering at final zoom level.
+- **Interim preview**: Show blurry upscaled/downscaled content during gestures; render at final zoom when gesture ends.
+
+### Network streaming strategies
+
+For large PDFs over slow networks:
+
+- **Byte-range requests**: Server sends only requested page ranges, not the entire PDF.
+- **Progressive rendering**: Render visible pages first; background requests fetch remaining pages.
+- **Server preprocessing**: Use the Syncfusion PDF Library to compress, optimize, or split large documents before serving.
+
+### Memory management for large documents
+
+On memory-constrained devices:
+
+- **Reduce worker pool size**: Fewer workers = lower memory overhead.
+- **Aggressive cache eviction**: Free resources aggressively; tolerate re-rendering cost.
+- **Limit zoom level**: Prevent users from zooming to extremely high levels that require huge bitmaps.
+- **Page tiling**: For very large pages, split into smaller tiles and render individually.
+
+**Quick tuning checklist:**
+
+- ✓ Enable DPR-aware scaling (check `devicePixelRatio` on init and on orientation change)
+- ✓ Implement visible-only page rendering or lazy loading
+- ✓ Cache decoded resources (images, fonts) and reuse across pages
+- ✓ Debounce or throttle zoom events to avoid excessive re-renders
+- ✓ For large PDFs: enable byte-range requests and progressive loading
+- ✓ Monitor memory usage; implement cache eviction if memory exceeds thresholds
+- ✓ Test on low-powered devices (older phones, tablets) to identify bottlenecks
+- ✓ Use Chrome DevTools Performance tab to profile rendering and identify slow stages
+
+**Performance monitoring:**
+
+Use browser APIs to measure rendering performance:
+
+```js
+// Measure render time
+const start = performance.now();
+await pdfViewer.renderPage(5);
+const renderTime = performance.now() - start;
+console.log(`Render time: ${renderTime}ms`);
+```
+
+See [Performance Optimization](#) for detailed configuration options and [Performance Profiling](#) for advanced diagnostics.
+
+## 9. Common issues & quick troubleshooting
+
+Rendering issues often trace to one of the stages in the pipeline. By understanding the likely cause, you can diagnose and resolve problems quickly.
+
+### Blurry output
+
+**Symptoms**: Text and graphics appear fuzzy or pixelated, especially on high-DPI displays.
+
+**Root causes**:
+- Incorrect `devicePixelRatio` handling (canvas buffer too small for physical pixels)
+- CSS transform or zoom applied after rendering
+- WebGL context loss and fallback to lower-quality rendering
+
+**Fixes**:
+1. Verify DPR at init and on orientation change:
+   ```js
+   console.log('devicePixelRatio:', window.devicePixelRatio);
+   ```
+2. Check canvas buffer size matches physical dimensions:
+   ```js
+   canvas.width = logicalWidth * devicePixelRatio;
+   ```
+3. Disable CSS zoom/transforms that conflict with canvas scaling.
+4. For high-resolution devices, consider reducing rendering quality to balance sharpness and performance.
+
+See [Rendering, Rasterization](#4-rendering-rasterization--vector-rendering--compositing) to know more about DPR conversion.
+
+### Text selection misalignment
+
+**Symptoms**: Selecting text doesn't highlight the correct characters; copy-paste gives wrong text.
+
+**Root causes**:
+- Font metric mismatch (embedded vs. fallback font)
+- Subset font glyph-to-character mapping errors
+- Transform matrix not applied correctly
+- CORS issues preventing embedded font loading
+
+**Fixes**:
+1. Check developer console for font loading errors:
+   ```
+   CORS error loading font from example.com
+   ```
+   Add CORS headers on font server.
+
+2. Verify PDF uses fully embedded fonts (not subsets). If subset fonts, enable server-side preprocessing:
+   ```js
+   const viewer = new PdfViewer({
+     serviceUrl: 'https://your-server.com/api/pdf'
+   });
+   ```
+
+3. For specific PDFs, test with server-side font optimization via the Syncfusion PDF Library.
+
+See [Section 5: HTML text layer](#5-html-text-layer-selectable-and-searchable-text) and [Section 6: Fonts](#6-fonts-embedding-subsetting-and-fallback).
+
+### Missing images
+
+**Symptoms**: Image placeholders or blank areas where images should appear; images render at lower quality than expected.
+
+**Root causes**:
+- Image stream decoding failures (unsupported format)
+- CORS restrictions preventing image loading
+- Memory limits preventing image decoding
+- Corrupted image data in the PDF
+
+**Fixes**:
+1. Check console for CORS errors:
+   ```
+   Access to image at 'https://external-domain.com/img.jpg' blocked by CORS policy
+   ```
+   Solution: Configure CORS on the external server or proxy through your server.
+
+2. Check for decoding errors. Enable debug logging to see which images fail.
+
+3. For unsupported image formats (e.g., JPEG2000), use server-side trans-coding:
+   ```js
+   const viewer = new PdfViewer({
+     serviceUrl: 'https://your-server.com/api/pdf/transcode'
+   });
+   ```
+
+4. If memory-constrained, implement image caching and eviction (see [Section 8](#8-device--performance-considerations)).
+
+See [Section 2: Resolve resources](#2-resolve-resources-fonts-images).
+
+### Worker failures
+
+**Symptoms**: PDF loads slowly or not at all; console shows worker errors; viewer falls back to main-thread rendering (UI becomes sluggish).
+
+**Root causes**:
+- Worker script not found (404) due to incorrect path
+- CORS policy blocking worker script load from different origin
+- SharedArrayBuffer disabled (security restriction on some browsers)
+- Worker quota exceeded (too many workers spawned)
+- Browser or environment doesn't support workers
+
+**Fixes**:
+1. Verify worker path is correct and accessible:
+   ```js
+   const viewer = new PdfViewer({
+     workerPath: '/assets/pdfviewer-worker.js'  // Verify file exists
+   });
+   ```
+
+2. Ensure worker script is served with correct `Content-Type`:
+   ```
+   Content-Type: application/javascript
+   ```
+
+3. Check CORS headers if workers are served from a different origin. Workers require same-origin by default.
+
+4. Reduce worker pool size if hitting quota limits:
+   ```js
+   const viewer = new PdfViewer({
+     workerCount: 2  // Reduce from default 4
+   });
+   ```
+
+5. Test fallback mode (disable workers) to isolate worker-specific issues:
+   ```js
+   const viewer = new PdfViewer({
+     workerCount: 0  // Disable workers
+   });
+   ```
+
+See [Section 7: Off-main-thread processing](#7-off-main-thread-processing-workers--wasm) and [Worker Troubleshooting](#).
+
+### Performance is sluggish
+
+**Symptoms**: Slow scrolling, delayed rendering, UI freezes during zoom operations.
+
+**Root causes**:
+- No visible-only rendering (rendering all pages instead of visible pages)
+- Excessive re-renders during continuous zoom or scroll
+- Worker pool too small for document complexity
+- Insufficient caching or aggressive cache eviction
+
+**Fixes**:
+1. Enable lazy rendering if document has many pages:
+   ```js
+   const viewer = new PdfViewer({
+     enableLazyRendering: true
+   });
+   ```
+
+2. Debounce zoom and scroll events:
+   ```js
+   viewer.on('zoom', debounce(() => { /* render */ }, 300));
+   ```
+
+3. Increase worker pool for high-complexity documents:
+   ```js
+   const viewer = new PdfViewer({
+     workerCount: 4
+   });
+   ```
+
+4. Profile with Chrome DevTools to identify bottleneck stage (parsing, rendering, etc.).
+
+See [Section 8: Device & performance considerations](#8-device--performance-considerations) and [Performance Profiling](#).
+
+**General diagnostic approach:**
+
+1. **Identify the stage**: Use browser DevTools Network, Performance, and Console tabs to pinpoint which stage fails.
+2. **Check logs**: Enable debug logging in the viewer to see intermediate steps.
+3. **Test fallbacks**: Disable workers, reduce quality, or use server preprocessing to isolate the root cause.
+4. **Isolate the PDF**: Test with simple PDFs (single page, no images) to rule out document-specific issues.
+5. **Check environment**: Verify browser version, device capabilities, and network conditions.
+
+## Related topics and further reading
+
+**Architecture and design:**
+- [Architecture of Syncfusion React PDF Viewer](../architecture/architecture-pdfviewer) – Component design, module interaction, and data flow
+- [Standalone vs Server-Backed Viewer](../architecture/standalone-vs-server-backed) – Client-only vs. hybrid architectures
+
+**Performance and optimization:**
+- **Performance Optimization** – Detailed tuning strategies, worker configuration, caching, and profiling
+- **Performance Profiling** – Using browser DevTools to measure and diagnose rendering bottlenecks
+- **Memory Management** – Cache policies, eviction strategies, and handling large documents
+
+**Rendering and styling:**
+- [Theming & Styling](../theming-and-styling) – Theme customization and CSS class reference
+- **Rendering Options** – Quality levels, rendering backends (Canvas, SVG, WebGL)
+
+**Resource handling:**
+- [Font Management](../how-to/custom-fonts) – Font subsetting, fallback strategies, and troubleshooting
+- **Image Optimization** – Server-side image preprocessing and CORS configuration
+- [Loading PDF Documents](../getting-started/loading-documents) – Document sources, streaming, and authentication
+
+**Advanced topics:**
+- **eb Worker Configuration** – Worker pool tuning, debugging, and fallback modes
+- [Server Integration](../server-integration/getting-started) – Using `serviceUrl` for preprocessing, OCR, and advanced features
+- [Troubleshooting Guide](../troubleshooting/troubleshooting) – Comprehensive issue resolution and FAQs
+- [Syncfusion PDF Library Documentation](../pdf-library/overview) – Server-side PDF processing and manipulation
+
+**Related technologies:**
+- [PDFium Reference](https://pdfium.googlesource.com/pdfium/) – Official PDFium documentation (external link)
+- [Canvas API Reference](https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API) – MDN Canvas documentation (external link)
diff --git a/Document-Processing/PDF/PDF-Viewer/react/architecture/pdf-standards-conformance.md b/Document-Processing/PDF/PDF-Viewer/react/architecture/pdf-standards-conformance.md
new file mode 100644
index 000000000..94327bb71
--- /dev/null
+++ b/Document-Processing/PDF/PDF-Viewer/react/architecture/pdf-standards-conformance.md
@@ -0,0 +1,94 @@
+---
+layout: post
+title: Supported PDF standards and conformance | Syncfusion
+description: Learn here all about supported PDF standards and conformance in Syncfusion React PDF Viewer and Component.
+platform: document-processing
+control: PDF Viewer
+documentation: ug
+---
+
+# Supported PDF standards and conformance
+
+This section explains the PDF standards supported by the Syncfusion React PDF Viewer and how the viewer handles PDF documents created according to standard specifications.
+
+## Overview
+
+The Syncfusion React PDF Viewer is engineered to **render and interact with PDF documents created according to standard PDF specifications**. It delivers accurate visual representation, smooth user interaction, and consistent behavior across different browser environments.
+
+The React PDF Viewer excels at **standards-based rendering and interaction**, providing users with a seamless viewing experience for a wide range of PDF documents created using industry-standard tools and processes.
+
+## PDF specification support
+
+The React PDF Viewer supports rendering PDF documents compliant with **ISO 32000 PDF specifications** (PDF 1.4 through 2.0), which define the structural and behavioral foundation of PDF files.
+
+The viewer provides comprehensive rendering capabilities for:
+- Text, images, and vector graphics with high fidelity
+- Embedded fonts and page resources for accurate layout preservation
+- Bookmarks and document outlines for enhanced navigation
+- Annotations and comments for collaborative workflows
+- Interactive form fields (AcroForms) with full user interaction support
+- Digital signatures with visual rendering and verification capabilities
+
+Documents created using standards-compliant PDF authoring tools are displayed and interacted with seamlessly in modern browser environments.
+
+## Viewing standards-generated PDF documents
+
+The React PDF Viewer excels at displaying documents generated for widely used PDF standards, including:
+
+- **Archival PDFs (PDF/A)** – long-term preservation documents with enhanced reliability
+- **Print-optimized PDFs (PDF/X)** – professionally prepared documents for printing workflows
+- **Tagged PDFs** – structurally enriched documents optimized for accessibility
+
+The viewer delivers **faithful layout rendering and intuitive user interaction**, empowering users to read, navigate, search, annotate, and review documents within web applications with confidence.
+
+## Conformance and standards handling
+
+The Syncfusion React PDF Viewer is optimized for **standards-based rendering and interaction**. The viewer leverages PDF documents that have been authored or processed in accordance with required PDF standards, ensuring optimal display quality and user experience.
+
+For enhanced control over PDF standard compliance and conformance requirements, the Syncfusion PDF Library provides comprehensive tooling for **document creation, conversion, and standards validation** as part of the document preparation pipeline.
+
+## Ideal use cases and applications
+
+The React PDF Viewer's standards-based rendering capabilities are optimized for:
+- **Enterprise document viewing portals** – delivering high-quality viewing across organizations
+- **Archival document access systems** – supporting long-term document preservation initiatives
+- **Compliance-driven environments** – enabling reliable viewing of standards-generated PDFs
+- **Interactive document review workflows** – facilitating annotation, collaboration, and feedback
+- **Health-care and financial systems** – meeting industry standards for document handling
+- **Legal and regulatory platforms** – supporting document management with confidence
+
+## Complementary solutions
+
+The Syncfusion React PDF Viewer excels at rendering and displaying PDF documents created according to standard PDF specifications, including archival, print-optimized, and tagged PDFs.
+
+By focusing on accurate display and responsive user interaction, the viewer ensures consistent, standards-aware document viewing with a rich user experience.
+
+### Expanding capabilities with the PDF Library
+
+The Syncfusion ecosystem provides complementary tools for comprehensive PDF workflows:
+
+**React PDF Viewer** – Expert rendering and interaction
+- Display standards-based PDFs
+- Intuitive navigation and search
+- Annotation and collaboration features
+- Form field interaction
+
+**Syncfusion PDF Library** – Advanced PDF processing
+- Create and generate PDF documents
+- Convert documents to PDF/A or PDF/X standards
+- Add digital signatures and security
+- Validate PDF compliance
+
+For scenarios that require PDF creation, conversion, or advanced standards processing, refer to:
+
+- [Working with PDF conformance in Syncfusion PDF Library (.NET)](https://help.syncfusion.com/document-processing/pdf/pdf-library/net/working-with-pdf-conformance)
+
+By leveraging both components, you can build comprehensive document management solutions with end-to-end standards support.
+
+## See also
+
+- [Architecture of Syncfusion React PDF Viewer](./architecture-pdfviewer)
+- [How PDF Rendering Works in the Browser](./how-pdf-rendering-works-in-browser)
+- [Standalone vs Server Backed PDF Viewer](./standalone-vs-server-backed-pdf-viewer)
+- [When backed PDF services are required](./when-backend-pdf-services-are-required)
+- [Self Hosted on](./self-hosted-on-prem-deployment)
\ No newline at end of file
diff --git a/Document-Processing/PDF/PDF-Viewer/react/architecture/performance-model-for-large-pdfs.md b/Document-Processing/PDF/PDF-Viewer/react/architecture/performance-model-for-large-pdfs.md
new file mode 100644
index 000000000..88b70919c
--- /dev/null
+++ b/Document-Processing/PDF/PDF-Viewer/react/architecture/performance-model-for-large-pdfs.md
@@ -0,0 +1,90 @@
+---
+layout: post
+title: Performance model for large PDFs | Syncfusion
+description: Learn here all about Performance model for large PDF files and performance considerations in Syncfusion React PDF Viewer.
+platform: document-processing
+documentation: ug
+control: PDF Viewer
+---
+
+# Performance model for large PDFs
+
+This section explains how the React PDF Viewer handles **large PDF documents** and outlines the performance model used to deliver a smooth viewing experience across different architectures and device capabilities.
+
+It also provides guidance on where performance optimizations are already covered in existing documentation and how they relate to this model.
+
+## Overview
+
+Rendering and interacting with large PDF documents requires careful handling of memory, CPU usage, and rendering pipelines. The React PDF Viewer follows a layered performance model that adapts based on the deployment mode and document complexity.
+
+With **version 31 and above**, significant performance improvements have been introduced—especially in **standalone (client-side) mode**—making the viewer capable of handling large PDFs efficiently without requiring back-end services in many scenarios.
+
+This page gives a high-level architectural view of these performance considerations.
+
+## Standalone viewer performance improvements (v31 and above)
+
+From version **31.x onward**, the standalone React PDF Viewer includes multiple optimizations that improve performance for large documents:
+
+- Incremental and on-demand page rendering
+- Reduced memory footprint during page navigation
+- Improved background worker coordination
+- Faster initial document load and page switch times
+
+These enhancements allow many large PDFs to be handled entirely on the client, provided the device has sufficient system resources.
+
+N> For most modern desktops and laptops, standalone mode is now suitable even for very large documents.
+
+## Large PDF handling strategy
+
+The PDF Viewer follows these principles when loading large documents:
+
+- Pages are rendered incrementally instead of all at once
+- Background tasks such as text extraction and thumbnail generation run independently
+- Rendering prioritizes visible pages to improve perceived performance
+
+This ensures faster user interaction while keeping memory usage under control.
+
+## How this performance model fits with large PDF optimization guides
+
+Detailed **implementation-level optimizations** for large PDFs—such as loading strategies and feature tuning—are covered in a separate User Guide.
+
+For best practices including:
+- Blob-based loading
+- Module minimization
+- Local storage optimization
+- Annotation and form-field handling
+
+See [Load Large PDF Files in React PDF Viewer](../document-handling/load-large-pdf) to know more about Large PDF Handling.
+
+This performance model page complements that guide by describing *why* those optimizations work from an architectural perspective.
+
+## Performance considerations
+
+The standalone (client-side) React PDF Viewer handles large PDF documents efficiently and is sufficient for most real‑world use cases, including very large files.
+
+Server‑backed processing is **not required for performance in typical scenarios**, but may be considered only in limited cases where external constraints exist, such as:
+
+- Documents exceed practical browser memory limits on specific environments
+- Uniform performance must be guaranteed across low‑end or highly constrained devices
+- PDFs require heavy batch processing or server‑side transformations
+- Enterprise environments mandate centralized control over resource usage
+
+In these scenarios, a server‑backed architecture offloads processing from the client while keeping the viewing experience responsive. For standard large‑PDF viewing and interaction, the standalone viewer remains the recommended approach.
+
+## Summary
+
+The React PDF Viewer uses an adaptive performance model designed to:
+
+- Handle large PDFs efficiently in standalone mode (v31 and above)
+- Scale processing based on document size and feature usage
+- Provide guidance-driven optimizations for heavy documents
+
+For implementation details and tuning, refer to the [Load Large PDF Files](../document-handling/load-large-pdf) guide. For architectural decisions, use this page to evaluate the appropriate performance model for your application.
+
+## See also
+
+- [Architecture of Syncfusion React PDF Viewer](./architecture-pdfviewer)
+- [How PDF Rendering Works in the Browser](./how-pdf-rendering-works-in-browser)
+- [Standalone vs Server Backed PDF Viewer](./standalone-vs-server-backed-pdf-viewer)
+- [When back-end PDF services are required](./when-backend-pdf-services-are-required)
+- [Self hosted on-premises Deployment](./self-hosted-on-prem-deployment)
diff --git a/Document-Processing/PDF/PDF-Viewer/react/architecture/self-hosted-on-prem-deployment.md b/Document-Processing/PDF/PDF-Viewer/react/architecture/self-hosted-on-prem-deployment.md
new file mode 100644
index 000000000..bf67064b0
--- /dev/null
+++ b/Document-Processing/PDF/PDF-Viewer/react/architecture/self-hosted-on-prem-deployment.md
@@ -0,0 +1,92 @@
+---
+layout: post
+title: Self-hosted / On-premises deployment in React PDF Viewer | Syncfusion
+description: Learn here all about Self-hosted / On-premises deployment in Syncfusion React PDF Viewer and component.
+platform: document-processing
+documentation: ug
+control: PDF Viewer
+---
+
+# Self-hosted / On-premises deployment in React PDF Viewer
+
+This section explains how the Syncfusion React PDF Viewer supports **self-hosted (on‑premises) deployment** and clarifies how the component operates without any dependency on cloud services.
+
+## Overview
+
+The Syncfusion React PDF Viewer is designed to work **entirely within your own infrastructure**. Once the license is purchased, the viewer can be deployed and used without relying on any Syncfusion cloud services.
+
+Both **standalone (client-side)** and **server-backed** deployments can be hosted on your own servers, making the PDF Viewer suitable for enterprise, intranet, and regulated environments.
+
+## No dependency on cloud services
+
+The React PDF Viewer does **not require any third‑party or Syncfusion‑managed cloud services** for production use:
+
+- PDF rendering and interaction can run fully in the browser (standalone mode)
+- Back-end PDF services, if used, are hosted and controlled by your organization
+- No document data is sent to Syncfusion servers
+- Licensing is not tied to runtime cloud usage
+
+This makes the viewer suitable for **air‑gapped**, **intranet‑only**, and **high‑security** deployments.
+
+## Standalone (client-side) deployment
+
+In standalone mode, all PDF rendering and interactions are handled directly in the browser using local resources.
+
+Key characteristics:
+- No back-end PDF service is required
+- PDFs are processed entirely on the client device
+- Ideal for read‑only viewing and interactive use cases
+- Recommended for most applications
+
+N> We strongly recommend using the **standalone mode** whenever back-end processing is not explicitly required.
+
+## Server-backed deployment (self-hosted)
+
+For scenarios that require server-side PDF processing, the React PDF Viewer can be configured to use a **self-hosted PDF Viewer web service**.
+
+Important notes:
+- The Web API hosted endpoint used in samples or code-snippet is **for demonstration and evaluation purposes only**
+- It must not be used in production environments
+- In production, you must host your own PDF Viewer web service
+
+You can self-host the server component by:
+- Reusing the official GitHub Web Service example, or
+- Deploying the provided Docker image in your environment
+
+Once deployed, the service endpoint is configured through the viewer’s `serviceUrl` property.
+
+## Client and server usage after purchase
+
+After purchasing a license:
+- The standalone PDF Viewer can be used without any additional services
+- Server-backed PDF processing can be hosted entirely on your own servers
+- No external cloud integration is required
+
+This gives you full control over:
+- Infrastructure
+- Security policies
+- Data access and storage
+- Deployment life-cycle
+
+## Typical self-hosted deployment scenarios
+
+Self-hosted or on‑premises deployments are commonly used when:
+- Documents must remain within internal networks
+- Regulatory or compliance requirements restrict cloud usage
+- Applications are deployed on private servers or data centers
+- Internal document management or enterprise portals are involved
+
+## Summary
+
+The React PDF Viewer fully supports **self-hosted and on‑premises deployment models**. Whether used in standalone browser mode or with a self-hosted back-end service, the viewer operates independently of any cloud services once licensed.
+
+For most use cases, the standalone mode is sufficient and recommended. Server-backed deployment should be used only when specific server-side processing requirements exist.
+
+## See also
+
+- [Architecture of Syncfusion React PDF Viewer](./architecture-pdfviewer)
+- [How PDF Rendering Works in the Browser](./how-pdf-rendering-works-in-browser)
+- [Getting Started standalone PDF Viewer](../getting-started)
+- [Getting Started Server Backed PDF Viewer](../getting-started-with-server-backed)
+- [Standalone vs Server Backed PDF Viewer](./standalone-vs-server-backed-pdf-viewer)
+- [When Back-end PDF Viewer are required](./when-backend-pdf-services-are-required)
\ No newline at end of file
diff --git a/Document-Processing/PDF/PDF-Viewer/react/architecture/standalone-vs-server-backed-pdf-viewer.md b/Document-Processing/PDF/PDF-Viewer/react/architecture/standalone-vs-server-backed-pdf-viewer.md
new file mode 100644
index 000000000..bc032f5a8
--- /dev/null
+++ b/Document-Processing/PDF/PDF-Viewer/react/architecture/standalone-vs-server-backed-pdf-viewer.md
@@ -0,0 +1,77 @@
+---
+layout: post
+title: Standalone vs Server-Backed PDF Viewer  | Syncfusion
+description: Compare standalone and server-backed PDF viewer modes to choose the best architecture for performance, scalability, and security.
+platform: document-processing
+control: PDF Viewer
+documentation: ug
+---
+
+# Standalone vs Server-Backed PDF Viewer
+
+This page helps developers and integrators understand the differences between standalone (client-side) and server-backed PDF viewer architectures, and choose the best approach based on performance, scalability, and deployment requirements.
+
+## Overview
+
+The Syncfusion React PDF Viewer can operate in two primary modes: **Standalone (client-side)** and **Server‑Backed**. Each mode defines where PDF processing occurs and how rendering, data flow, and interactions are handled.
+
+This page compares both approaches, highlights their strengths and limitations, and explains why a standalone client-side viewer is often the preferred choice for modern, high-performance web applications.
+
+See [Getting Started](../getting-started) and [Getting Started with Server Backed](../getting-started-with-server-backed) to start working with Standalone and Server Backed PDF Viewer.
+
+## Architectural models
+
+### Standalone (Client-side) viewer
+
+In standalone mode, PDF parsing, rendering, annotation handling, and user interactions are executed entirely within the browser. The viewer loads the PDF directly from a URL or local source and processes it using browser technologies such as Canvas, Web Workers, and WASM.
+
+This model minimizes network latency, reduces server dependency, and provides faster interaction for most viewing and annotation scenarios.
+
+### Server-backed viewer
+
+In server-backed mode, the browser acts primarily as a presentation layer. PDF processing operations—such as parsing, rendering, import/export, and sometimes annotations—are performed on a back-end service, with the client receiving processed data or rendered output.
+
+This model is typically used when documents must remain on the server due to compliance, centralized control, or heavy server-side workflows.
+
+## Standalone vs server-backed comparison
+
+The following table summarizes the key differences between standalone and server-backed viewer architectures.
+
+| Aspect | Standalone (Client-side) | Server-backed |
+|------|--------------------------|---------------|
+| **Rendering location** | Browser (Canvas / SVG / WASM) | Server-side service |
+| **Performance** | Faster UI response, low latency | Network-dependent, higher latency |
+| **Scalability** | Scales with client devices | Scales with server resources |
+| **Server load** | Minimal or none | High (CPU, memory, I/O intensive) |
+| **Offline support** | Possible (cached/local PDFs) | Not supported |
+| **Deployment complexity** | Simple (static hosting) | Requires back-end infrastructure |
+| **Cost** | Lower operational cost | Higher infrastructure cost |
+| **Customization** | High (client-side events and hooks) | Limited by server APIs |
+| **Typical use cases** | Viewing, annotations, forms, fast navigation | Compliance-heavy, controlled environments |
+
+## Why standalone (client-side) is preferred
+
+For most web applications, a standalone client-side viewer offers significant advantages. Rendering directly in the browser eliminates round-trip delays to the server, resulting in faster page load times, smoother scrolling, and instant annotation feedback.
+
+Standalone viewers also simplify deployment by removing dependency on back-end services. This makes them ideal for cloud-native applications, SPAs, and scenarios where responsiveness and user experience are critical.
+
+## When to choose a server-backed viewer
+
+A server-backed viewer may be appropriate when strict data control is required, such as:
+
+- Documents must never be exposed to the client
+- Centralized processing and auditing are mandated
+- Heavy server-side workflows are already in place
+
+In these cases, the additional latency and infrastructure cost are acceptable trade-offs for compliance and centralized control.
+
+## Decision guidance
+
+If performance, scalability, and ease of deployment are your primary concerns, a **standalone client-side PDF viewer** is the recommended option. A server-backed approach should be selected only when regulatory or architectural constraints explicitly require server-side processing.
+
+## See also
+
+- [Architecture of Syncfusion React PDF Viewer](./architecture-pdfviewer)
+- [How PDF Rendering Works in the Browser](./how-pdf-rendering-works-in-browser)
+- [Getting Started standalone PDF Viewer](../getting-started)
+- [Getting Started Server Backed PDF Viewer](../getting-started-with-server-backed)
diff --git a/Document-Processing/PDF/PDF-Viewer/react/architecture/when-backend-pdf-services-are-required.md b/Document-Processing/PDF/PDF-Viewer/react/architecture/when-backend-pdf-services-are-required.md
new file mode 100644
index 000000000..944e37b62
--- /dev/null
+++ b/Document-Processing/PDF/PDF-Viewer/react/architecture/when-backend-pdf-services-are-required.md
@@ -0,0 +1,79 @@
+---
+layout: post
+title: When back-end PDF services are required | Syncfusion
+description: Learn here all about when and why back-end (server-side) PDF services are required in Syncfusion React PDF Viewer.
+platform: document-processing
+documentation: ug
+control: PDF Viewer
+---
+
+# When back-end PDF services are required
+
+This section explains **when and why back-end (server-side) PDF services are required** for the React PDF Viewer and helps you decide whether a server-backed architecture is necessary for your application.
+
+## Overview
+
+The React PDF Viewer can operate entirely in the browser using a [standalone](../getting-started) (client-side) architecture. However, certain functional, security, and performance requirements make it necessary to process PDF operations on a back-end server.
+
+This page outlines the key decision factors for selecting a [server-backed PDF viewer](../getting-started-with-server-backed).
+
+## Security & Compliance Requirements
+
+back-end PDF services are required when PDF documents or operations must adhere to strict security and compliance standards.
+
+Use server-side processing when:
+- PDF files must not be directly exposed to end users
+- Document access is restricted by enterprise security policies
+- Compliance with regulations such as HIPAA, GDPR, or SOC is required
+- Operations involve certificates, private keys, or confidential data
+- Centralized auditing, logging, or access control is mandatory
+
+In these scenarios, all sensitive PDF operations are executed within a controlled server environment.
+
+## Large-scale or resource-intensive processing
+
+Browser-based PDF processing is limited by device memory and CPU constraints. back-end services are recommended for:
+
+- Large PDF documents with high page counts
+- Complex PDFs containing heavy graphics or embedded assets
+- Batch or bulk operations such as merging, splitting, or text extraction
+
+Server-side processing ensures reliable execution and allows applications to scale without impacting client performance.
+
+## Performance & consistency on low-end devices
+
+PDF processing behavior can vary across browsers and hardware configurations. Server-backed services provide consistent behavior when:
+
+- Users access the application on low-end or older devices
+- Mobile or tablet environments are frequently used
+- Browser memory limits affect rendering or interactions
+
+In a server-backed setup, processing is performed on the server while the client focuses on rendering and user interaction.
+
+## Typical use cases
+
+A server-backed PDF viewer is commonly used in:
+
+- Enterprise document management systems
+- Internal applications with restricted document access
+- Banking, health-care, and government solutions
+- High-volume or compliance-driven PDF workflows
+
+## Getting started with a server-backed PDF viewer
+
+If your application requires back-end PDF services, refer to the following guide to configure and integrate a server-backed PDF viewer:
+
+[Getting started with server-backed React PDF Viewer](https://help.syncfusion.com/document-processing/pdf/pdf-viewer/react/getting-started-with-server-backed)
+
+This guide covers back-end service setup, required endpoints, and client-server configuration details.
+
+Use a **server-backed PDF viewer** when security, compliance, scalability, or performance consistency is critical. For lightweight viewing and basic interactions, a standalone client-side viewer may be sufficient.
+
+## See also
+
+- [Architecture of Syncfusion React PDF Viewer](./architecture-pdfviewer)
+- [How PDF Rendering Works in the Browser](./how-pdf-rendering-works-in-browser)
+- [Getting Started standalone PDF Viewer](../getting-started)
+- [Getting Started Server Backed PDF Viewer](../getting-started-with-server-backed)
+- [Standalone vs Server Backed PDF Viewer](./standalone-vs-server-backed-pdf-viewer)
+
diff --git a/Document-Processing/PDF/PDF-Viewer/react/images/high-level-components.png b/Document-Processing/PDF/PDF-Viewer/react/images/high-level-components.png
new file mode 100644
index 000000000..46dc86f5e
Binary files /dev/null and b/Document-Processing/PDF/PDF-Viewer/react/images/high-level-components.png differ
diff --git a/Document-Processing/PDF/PDF-Viewer/react/images/worker-message-flow.png b/Document-Processing/PDF/PDF-Viewer/react/images/worker-message-flow.png
new file mode 100644
index 000000000..ef9d51853
Binary files /dev/null and b/Document-Processing/PDF/PDF-Viewer/react/images/worker-message-flow.png differ