Your ECM's built-in viewer is
slow, limited, and leaking data.
It can't open TIFFs. It chokes on CAD drawings. It won't render email attachments. So people download documents locally, compare contracts by opening two windows side by side, and annotate by printing and scanning back in. Every downloaded file is a security hole. Every workaround costs time.
The daily reality of a viewer that wasn't built for the job
When the viewer fails, users find workarounds. Each one costs time, creates risk, and moves your data outside the perimeter you think you control.
Real organizations, similar problems
These are not pilots or proofs of concept. They are production deployments that have been running for nearly a decade.
A healthcare IT organization serving 370+ hospitals
Their users were complaining. The existing viewer was, in their own words, "simple and simplistic." Hospital staff deal with heterogeneous document types in a regulated, HDS-certified environment where data integrity is non-negotiable. They replaced the built-in viewer with Uxopian's document viewing layer. The plan now is to generalize it across all seven of their software products. The partnership has lasted nearly 10 years.
"ARender was a true technological leap, from something simple and simplistic to a dedicated tool that's truly built for the job."
Innovation Lead, Healthcare IT Organization serving 370+ Hospitals
A European e-signature provider processing millions of signatures
They needed to render PDFs and place signature boxes inside their own product. Building a rendering engine from scratch would have pulled their team away from what they actually do: digital trust and electronic signatures. They chose to embed Uxopian's rendering API instead. Docker-based deployment. Full control over the signing experience. The integration has been running for nearly 10 years, powering millions of signatures.
"We needed a rendering solution that could scale with our growth, while keeping full control over the signing experience."
Technical Lead, Leading European E-Signature Provider
What runs behind this
A server-side rendering engine sits between your applications and your ECM repositories. It converts any document format into rendered images before they reach the browser. The original file never moves.
Business portals
Case management
Employee self-service
Custom apps
ARender
Server-side rendering · annotation (XFDF) · version comparison · search · redaction · REST API · JavaScript API
Alfresco
Nuxeo
OpenText
FileNet, M-Files, S3
Deploy on-premises, in your private cloud, or as SaaS. European-origin software. Your data stays on your infrastructure.
From workarounds to a viewer that actually works
Each capability below removes one of the workarounds your team has been living with. They all come from a single server-side rendering layer that sits in front of your existing ECM.
250+ types render server-side. The first page appears in milliseconds. No plugins, no downloads, no exceptions.
Server-side rendering means the original file never touches the browser. What the user sees is a rendered image.
check_circle250+ formats, zero downloadsOnly rendered images reach the browser. The original file stays on your infrastructure.
For organizations under GDPR, HDS, or equivalent frameworks, this is the difference between controlled access and uncontrolled exposure.
securityZero-trust document accessTextual and pixel-level comparison with synchronized scrolling. Place two versions side by side and see exactly what changed.
Every modification is highlighted. Every deletion is flagged. Legal and compliance teams go from a 30-minute manual review to a 2-minute visual confirmation.
diffPixel-level version diffNotes, highlights, stamps, freehand markups, and audio annotations. Stored separately in Adobe XFDF format. Every annotation is searchable, traceable, and tied to a user.
edit_noteXFDF annotations, full traceabilityPre-built connectors for Alfresco, Nuxeo, OpenText, M-Files, FileNet, Documentum, Salesforce, and S3.
hubAll ECMs, single integrationIndustries that deal with this every day
Every regulated industry has its own version of the same problem: too many document formats, too many workarounds, and a compliance posture that erodes every time someone downloads a file.
Patient records combine PDF discharge summaries, multi-page TIFF prescriptions, DICOM imaging, and scanned consent forms. Server-side rendering keeps the original on HDS-certified infrastructure and delivers only a rendered image to the clinician's browser.
Claims dossiers mix police reports, scanned photos, expert appraisals, and email threads. Adjusters compare versions, flag discrepancies, and redact personal data before forwarding to external counsel.
FOIA requests require redaction of personal data before public release. Staff select exemption reasons from a structured dropdown. Every redaction is logged, reproducible, and defensible in an audit.
You're building a product that handles documents, but document rendering is not your core business. You need an API that can render any format, place elements on pages, and scale with your user base.
The longer you wait, the more documents leave your perimeter
This is not a UX problem. It is a compliance and data governance problem that happens to manifest as a UX problem.
Every download is a data leak you chose not to prevent
GDPR requires data minimization and access control. When users download sensitive documents because the viewer can't display them, you lose control.
If a laptop is lost or compromised, those files go with it. Regulators will ask what you did to prevent it.
Redaction requirements are growing, not shrinking
FOIA requests, GDPR subject access requests, litigation holds. You need to redact personal data reliably, permanently, and with an audit trail.
If your current viewer has no redaction capability, your team is doing this manually in a PDF editor.
The GDPR answer regulators want to hear
Every document accessed in our systems is rendered server-side. The original file never reaches the user's device. We have a full access log. Annotations are XFDF-stored and traceable. Downloads require explicit authorization.
You have options. Here's how they compare.
Developer SDKs give you building blocks. Mobile-first SDKs optimize for tablets. ECM native viewers cover the basics. None of them were built for the problem you actually have.
| What matters | Uxopian (ARender) | Developer SDKs | Mobile-first SDKs | ECM native viewers |
|---|---|---|---|---|
| Format coverage | 250+ formats: PDF, Office, TIFF, CAD, DICOM, email, legacy | 100+ formats, PDF-focused | PDF-centric, no CAD or DICOM | Limited to vendor formats |
| Where rendering happens | Server-side. Zero-trust by design. | Client-side SDK | Client-side (WebAssembly) | Varies, typically client-side |
| Version comparison | Native textual and pixel-level diff | Not available | Not a core feature | Typically not available |
| Annotations | Notes, stamps, highlights, XFDF. Full audit trail. | SDK-level APIs | Annotation SDK | Basic or none |
| Multiple ECMs | Alfresco, Nuxeo, OpenText, M-Files, FileNet, S3 | No ECM connectors | No ECM connectors | Own repository only |
| Deployment | On-prem, private cloud, SaaS. European-origin. | On-prem/cloud, US-based | Cloud/on-prem, Austria | Tied to ECM |
What happened after deployment
These numbers come from production deployments.