-
MathType
-
WirisQuizzes
-
Nubric
-
CalcMe
-
MathPlayer
-
Store FAQ
-
MathFlow
-
BF FAQ
-
Miscellaneous
-
Wiris Integrations
MathType integrations architecture
Reading time: 3minMathType integrations are built on a modular architecture that separates the editor integration (frontend) from the processing and rendering logic (services). Understanding this architecture helps you choose the right deployment model and configuration for your needs.

The three-layer architecture
MathType integrations follow a three-layer architecture:
- MathType integration frontend (client-side).
- MathType integration services (server-side or cloud).
- MathType editor services (core processing layer).
These components work together to enable formula editing, rendering, accessibility generation, and storage within web-based editors. This architecture is designed to:
- Decouple UI integration from processing logic.
- Support both cloud and on-premises deployments.
- Allow flexible configuration depending on infrastructure needs.
MathType integration frontend
The part that runs in the browser and connects MathType to the editor (TinyMCE, CKEditor, Froala, and others).
MathType integration services
Middleware that processes requests between the frontend and MathType editor services.
MathType editor services
Core MathType services responsible for formula processing and rendering tasks, such as:
- Formula rendering.
- Accessibility generation.
- Math processing.
- Editor functionality.
These services are hosted by default in the MathType cloud, but can also be self-hosted with the appropriate license.
The frontend integration is configured to work with MathType cloud services by default. Most customers will find these service settings sufficient. Only customers who need specific infrastructure, security, or deployment requirements should consider self-hosting services.
How the components interact
Stage 1: MathType integration frontend (client-side)
The frontend integration is a JavaScript component embedded into the editor. It is responsible for:
- Adding MathType and ChemType buttons to the toolbar.
- Opening the MathType editor interface.
- Sending requests to integration services.
- Inserting and editing formulas within the editor content.
By default, the frontend connects to MathType cloud services.
Stage 2: MathType integration services (middleware layer)
Integration services act as a bridge between the frontend and MathType editor services. They:
- Receive requests from the frontend.
- Call MathType editor services.
- Transform and return responses to the frontend.
These services are available in Java and PHP and can be hosted either in the cloud or on your own infrastructure.
Stage 3: MathType editor services (core processing)
This is the core layer that handles:
- Rendering formulas.
- Generating accessible representations.
- Processing mathematical input.
These services are hosted by default in the MathType cloud, but can also be deployed on-premises with the appropriate license.
Stage 4: End-to-end flow
A typical formula lifecycle works as follows:
- User clicks the MathType button in the editor.
- The frontend opens the MathType editor.
- Integration services communicate with MathType editor services.
- The user creates or edits a formula.
- The formula is processed and rendered.
- The result is returned to the frontend.
- The formula is inserted into the editor content.
Deployment models
MathType integrations support several deployment models depending on your infrastructure and security requirements. The most common deployment models are:
- Default cloud deployment.
- Self-hosted Integration Services.
- Fully self-hosted deployment.
Each model offers a different balance between operational simplicity, customization, and infrastructure control.
For a detailed comparison of deployment options, see MathType integrations deployment models.
Frontend vs Integration Services responsibilities
In all deployment models, the frontend is responsible for editor interaction, while services handle formula processing, rendering, storage, and other backend responsibilities. The following table summarizes where different configuration options are applied:
MathType Editor services location |
Integration frontend |
Integration services |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
(1) GUI Properties can be changed from both parts, the integration frontend and the integration services. See an example of both ways to configure the GUI at Mathtype Editor parameters.
(2) For fine-tuning of MathType editor services (i.e., custom fonts), hosting MathType editor services on your end with the appropriate server components license is mandatory. You can see more details about it at MathType Integrations deployment models.
(3) You can see a complete list of the configuration parameters supported by MathType Integration Services at MathType Integration Services parameters.
Key differences
Frontend handles
- Toolbar configuration.
- Editor UI behavior.
- Basic GUI properties.
Integration services handle
- Formula rendering format.
- Content storage format.
- Image caching and storage location.
- Proxy and cross-domain configuration.
- Performance optimization.
Common Misunderstandings
MathType is just a frontend plugin
The frontend is only one part of the system. Rendering, storage, and processing depend on backend services.
All configurations can be done in the editor
Many important settings, such as rendering, storage, caching, and performance, can be configured only through integration services.
.png)
