WebAssembly

For many years, professional document processing and browser applications were considered incompatible.

Rich document editing required desktop applications. Professional formatting engines needed to be executed locally. True WYSIWYG experiences were difficult to achieve in a web browser.

At Text Control, however, we took a different approach.

Rather than simplifying document editing for the web, we brought the full document processing engine to the server and connected it to the browser via WebSockets. This architecture enabled applications to provide users with the professional editing experience, document fidelity, and formatting accuracy they expected from desktop software.

Today, this technology powers document processing solutions around the world.

Organizations use TX Text Control's WebSocket-based architecture to develop enterprise applications for creating, editing, reviewing, and processing business-critical documents. This approach remains one of the most capable for delivering professional document editing experiences through the browser.

The Browser Keeps Getting More Powerful When we first introduced our WebSocket-based document processing architecture, browsers were very different from what they are today. Modern browsers now offer features that would have seemed impossible just a few years ago. One of the most significant developments has been the rise of WebAssembly.

What is WebAssembly?

WebAssembly (Wasm) is a web standard that allows native applications and libraries to run directly in the browser. Code written in languages such as C++ can be compiled into a compact binary format that executes securely and efficiently within modern browsers.

This enables sophisticated software, including document editors, to perform complex calculations, rendering operations, and other demanding workloads locally in the browser rather than relying entirely on server-side processing.

For the first time, browsers can execute highly optimized native code suitable for sophisticated applications that previously required desktop installations or server-side execution.

This raises an exciting question for us:

What becomes possible when professional document processing can execute directly inside the browser?

A Long-Term Investment in the Future of Document Editing Several years ago, we began exploring that question.

It wasn't because our existing architecture had limitations for enterprise applications. Quite the opposite, in fact.

Our WebSocket-based technology remains the foundation for countless production systems and is still the preferred architecture for many enterprise deployment scenarios.

However, we also recognized that WebAssembly represents a significant shift in browser technology. We wanted to understand how far we could push browser-based document processing while maintaining the features that define TX Text Control.

True WYSIWYG editing Professional document layout Consistent rendering High-fidelity document compatibility Enterprise-grade reliability It is not a simple task to achieve those goals inside a pure browser environment. A professional document engine requires decades of engineering, sophisticated layout algorithms, rendering technologies, formatting logic, and compatibility features. Integrating that level of functionality into WebAssembly requires substantial architectural work and years of investment. This investment has been underway for quite some time.

Consistency Remains the Goal One principle has guided every generation of TX Text Control technology:

Documents should look the same, no matter where they are processed.

A document opened in a WebSocket-based TX Text Control application and the same document opened in a future WebAssembly-based application should produce the same layout, page flow, formatting, and visual appearance.

Users expect consistency when a document is rendered on a desktop, processed on a server, or edited in a browser. They expect the formatting to remain intact. They expect the layout to be predictable. They expect a true WYSIWYG experience.

This expectation does not change with WebAssembly.

In fact, preserving this consistency is one of the central goals of our WebAssembly initiative. We are not interested in creating a lightweight editor or a limited browser experience. Our goal is to provide developers with the same professional document processing capabilities they already know from TX Text Control in a pure browser environment.

Why We Chose Native WebAssembly Instead of Blazor We expect developers to ask one question: Why did we not build the editor on top of Blazor and the .NET runtime in the browser?

The answer lies in performance, rendering accuracy, and having complete control over the editing experience.

Professional document editing is one of the most demanding workloads that can run in a browser. Each keystroke, cursor movement, formatting operation, page break calculation, and rendering update must occur instantly while maintaining a consistent WYSIWYG experience.

For TX Text Control, document fidelity has always been the highest priority.

Our rendering engine, refined over decades, ensures consistent display and formatting of documents across platforms and deployment scenarios. Bringing this technology into the browser required an architecture that would allow us to maximize performance while maintaining complete control over rendering and layout calculations.

After evaluating different approaches, we decided to build a native WebAssembly solution based on C++ . Instead of adding an extra runtime layer to the browser, we compile our rendering and document engines directly to WebAssembly. This enables the browser to execute the core editing and rendering logic with minimal overhead while maintaining the performance necessary for professional document editing.

Maintaining Control Over the Rendering Pipeline Another important factor was our commitment to maintaining ownership of the rendering pipeline.

Many modern browser-based editors rely on large third-party rendering frameworks or open-source graphics engines, such as Skia. While these technologies are impressive and suitable for many applications, they introduce additional dependencies and external release cycles. Ultimately, they also introduce rendering behavior outside of our direct control.

We believe that the rendering engine itself is a strategic asset for a product whose primary purpose is accurate document rendering and editing. This philosophy has guided the development of TX Text Control for decades. We build and maintain the core technology ourselves for critical processing pipelines such as document layout and rendering, PDF generation, format import and export, and document conversion. Ownership of this technology gives us complete control over quality, compatibility, performance, and long-term product direction, while minimizing our dependence on external frameworks and rendering engines.

By investing in our own rendering technology and bringing it to WebAssembly, we retain control over rendering behavior, compatibility decisions, performance optimizations, and product direction. This enables us to ensure consistent document appearance across platforms independent of external rendering projects.

The result is an architecture specifically optimized for demanding document workloads:

Faster startup times Lower memory consumption Highly responsive editing Predictable rendering behavior Full control over the rendering pipeline Minimal external dependencies Consistent WYSIWYG document layout Most importantly, this approach enables us to incorporate the rendering principles that have defined TX Text Control for decades into the browser itself.

Our goal wasn't just to create a document editor with WebAssembly. We aimed to create a professional TX Text Control editor that provides the performance, accuracy, and WYSIWYG experience our users expect all within a modern web browser.

See It in Action The existence of a WebAssembly document editor raises an obvious question:

Is the document being processed entirely in the browser, or is a server still involved behind the scenes?

The following demonstrations show what can already be done with our current implementation. In these examples, the document is processed entirely in the browser without any server involvement. The rendering, layout, formatting, and editing logic all execute locally in WebAssembly.

Fast Initialization The first video highlights the editor's startup performance. After pressing F5 to reload the page, the complete initialization process is shown from start to finish.

One of our primary goals was to minimize startup time and provide a responsive editing experience as soon as the application loads. By compiling our native document engine directly to WebAssembly, the editor can quickly initialize without a server-side document processing backend.

Loading Documents Without a Server One of the most interesting deployment scenarios enabled by WebAssembly is the ability to build offline-only document editing applications.

Documents can be stored locally on the user's device, in browser storage, or within an offline web application. They can then be loaded directly into the editor, eliminating the need for a server-side document processing component.

The following video shows a document being dragged from the local file system into the editor. The document loads, parses, and renders entirely within the browser. No upload takes place, and no server communication is required.

Editing Without Server Communication The most interesting aspect of the architecture may be what does not happen.

The third video shows the browser's developer tools in action while editing a document. As text is entered, formatted, and modified, no HTTP requests, WebSocket messages, or background communication with a server occur.

All document processing, layout calculation, rendering, and editing operations execute locally inside the browser.

For organizations with strict security, privacy, or offline requirements, this opens up new deployment possibilities. Applications can provide professional document editing capabilities without requiring documents to leave the client device.

This architecture enables a new class of applications in which document editing remains fully functional even when a network connection is unavailable.

Built for the .NET Ecosystem, Designed for More As with all TX Text Control products, our initial focus is on the .NET ecosystem.

The first WebAssembly release is planned as an easy-to-integrate NuGet package for ASP.NET Core and Blazor applications. Using familiar .NET development workflows, tooling, and deployment models, developers will be able to add professional document editing capabilities to existing applications.

This approach enables us to provide a streamlined experience for the substantial community of developers who are already building business applications on the Microsoft platform.

At the same time, one advantage of a WebAssembly-based architecture is its platform independence.

Once the document engine executes directly inside the browser, the surrounding application framework becomes less important. No matter what framework an application is built with: ASP.NET Core, Blazor, Angular, React, Vue, or plain JavaScript. The same WebAssembly engine can provide the underlying document editing capabilities.

For this reason, we view the initial .NET integration as the first step, not the final destination.

Our long-term vision is an ecosystem that enables developers to integrate TX Text Control's document editing technology into frameworks and platforms that best fit their application architecture. Although our immediate focus is on providing the best possible experience for .NET developers, the underlying technology creates opportunities that extend far beyond a single framework or development platform.

Compatibility with Existing Applications One of our primary goals is to make the transition to WebAssembly as simple as possible for our existing customers using TX Text Control.

Many organizations have invested significant time and effort in integrating TX Text Control into their ASP.NET Core applications using our current WebSocket-based architecture. These applications continue to perform well and are fully supported.

The introduction of WebAssembly does not require a complete redesign or migration project.

Instead, we aim to provide a compatible path forward that allows developers to adopt the new technology while preserving their existing investments in applications, development knowledge, and integration patterns wherever possible.

For many applications, WebAssembly offers additional deployment flexibility. By moving document processing and rendering directly into the browser, server-side infrastructure requirements can be significantly reduced or eliminated entirely in some scenarios. This can lower operational costs, simplify deployments, and eliminate server-side scaling constraints associated with document editing workloads.

It also creates new opportunities for highly scalable applications. Since document editing operations execute on the client device, application growth is no longer directly tied to proportional increases in document processing infrastructure.

Perhaps most importantly, developers do not need to wait for WebAssembly to become available before starting new projects.

Applications built today using TX Text Control's WebSocket-based architecture are built on the same document editing technology and concepts that will continue to drive our future development. When the time comes, organizations will be able to evaluate and adopt WebAssembly based on their requirements and deployment goals.

In other words, choosing TX Text Control today does not mean choosing between WebSockets and WebAssembly. It is an investment in a document editing platform that continues to evolve and adapt to new technologies. It is an investment in an evolving document editing platform that protects existing applications and development investments.

Looking Ahead Today, our WebSocket-based architecture remains a proven and widely deployed foundation for browser-based document editing with TX Text Control. It continues to power enterprise applications around the world and will remain an important part of our platform going forward.

At the same time, WebAssembly introduces new possibilities for deploying document editing applications. By moving document processing, rendering, and editing directly into the browser, it enables scenarios that can reduce infrastructure requirements, simplify scaling, and support fully offline applications.

WebAssembly is being developed alongside our existing WebSocket technology as a compatible addition to the TX Text Control platform. Applications built today benefit from the same document technology and concepts that continue to drive our future development.

For us, WebAssembly is not about replacing a successful technology. It is about extending the TX Text Control platform with new capabilities and deployment options while maintaining compatibility with existing applications and investments.

We look forward to sharing more technical details and demonstrations in the months ahead.

Frequently Asked Questions What is TX Text Control WebAssembly? TX Text Control WebAssembly is a future browser-based document editing technology that brings the TX Text Control document and rendering engine directly into the browser using native WebAssembly.

Does WebAssembly replace the current WebSocket-based editor? No. The current WebSocket-based architecture remains a core part of the TX Text Control platform and continues to be the recommended solution for many enterprise applications.

Can existing WebSocket-based applications move to WebAssembly later? Yes. One of our goals is to provide a compatible path forward so existing TX Text Control applications can adopt WebAssembly technology while preserving existing investments and integration patterns wherever possible.

Why is TX Text Control using native WebAssembly instead of Blazor WebAssembly? Professional document editing requires high performance, predictable rendering, and full control over layout calculations. TX Text Control uses native C++ document and rendering technology compiled directly to WebAssembly to avoid additional runtime overhead and preserve true WYSIWYG behavior.

Does document processing happen on the server? In the WebAssembly version, document processing, layout calculation, rendering, and editing operations are designed to execute directly in the browser. This enables scenarios where documents can be edited without server-side document processing.

Can WebAssembly enable offline document editing? Yes. Because the document engine runs in the browser, documents can be loaded from local storage, browser storage, or offline web applications and edited without requiring a network connection.

Will the WebAssembly version support .NET applications? Yes. The first version is planned as a .NET-focused NuGet package for easy integration into ASP.NET Core and Blazor applications.

Will other frameworks be supported in the future? The underlying WebAssembly architecture is framework-independent. While the first release focuses on .NET, future integrations can include Angular, React, Vue, plain JavaScript, and other browser-based application platforms.

Why does TX Text Control maintain its own rendering pipeline? Accurate document rendering is a strategic part of TX Text Control. We build and maintain our own document layout, rendering, PDF generation, import and export, and document conversion pipelines to ensure consistent quality, compatibility, performance, and long-term control.

How does WebAssembly affect scalability and server costs? By moving document editing workloads to the client device, WebAssembly can reduce or eliminate server-side document processing infrastructure in certain scenarios. This can lower operational costs and make applications easier to scale.

TX Text Control .NET Server

DS Server

Server & Web

Windows Forms

WPF

ActiveX

Core Technologies

Blog

Core Technologies

Blog

Authors

Latest Posts

Support Resources

Documentation

Support

Getting Started

Other Resources

About Us

Industry events

Company

Contact

Newsletter

Legal

Sign in

Create account

Text Control Account

WebAssembly

Post tagged with WebAssembly in 2026

Server & Web

Windows Forms

WPF

ActiveX

Core Technologies

​

Latest Posts

​

Support

Getting Started

​

Other Resources

Company

Contact

Newsletter

Legal

Text Control Account

​

​

WebAssembly

Post tagged with WebAssembly in 2026 ​

June 2026

Post tagged with WebAssembly in 2026