Welcome to our combined .NET servicing updates for June 2026. Let’s get into the latest release of .NET & .NET Framework, here is a quick overview of what’s new in our servicing releases:

Security improvements

.NET and has been refreshed with the latest update as of June 9, 2026. This update contains security and non-security fixes.

This month you will find that these CVEs have been fixed:

Release changelogs

• ASP.NET Core: 10.0.9
• Runtime: 10.0.9 | 9.0.17 | 8.0.28

.NET Framework June 2026 Updates

This month, there are no new security or new non-security updates available. For recent .NET Framework servicing updates, be sure to browse our release notes for .NET Framework for more details.

See you next month

That’s it for this month, make sure you update to the latest service release today.

The post .NET and .NET Framework June 2026 servicing releases updates appeared first on .NET Blog.

Agentic applications stop being simple very quickly. A useful assistant rarely stays as one model call. It needs tools, live data, specialized agents, orchestration, memory, voice or chat entry points, deployment infrastructure, health checks, and observability.

That is the story behind the AlpineAI ski resort demo. It is a distributed, multi-agent application built with Microsoft Agent Framework (MAF), Microsoft Foundry, A2A, Voice Live, and Aspire. The scenario is intentionally realistic: a ski resort concierge that can answer guest questions, reason over live resort telemetry, route requests to specialist agents, search the web for general ski knowledge, and support both chat and voice experiences.

The important part is not that the demo is about skiing. The important part is how Aspire turns a complex multi-agent system into one application graph you can run, observe, and publish.

Before getting into the full demo, it helps to separate the Foundry concepts Aspire is modeling using the Aspire.Hosting.Foundry integration.

Start with Foundry in Aspire

Microsoft Foundry gives agentic apps managed AI infrastructure: projects, model deployments, tools, prompt agents, hosted agents, and realtime capabilities. Aspire lets you describe those pieces in the same AppHost that describes the rest of your application.

Foundry accounts, projects, and model deployments

A Foundry account is the top-level Microsoft Foundry resource. A Foundry project is the workspace inside it where model deployments, tools, and agents live:

C# AppHost

var foundry = builder.AddFoundry("ai");
var project = foundry.AddProject("project");

var chat = project.AddModelDeployment("chat", FoundryModel.OpenAI.Gpt41);
var realtime = project.AddModelDeployment("realtime", FoundryModel.OpenAI.GptRealtime);

TypeScript AppHost

const foundry = await builder.addFoundry('ai');
const project = await foundry.addProject('project');

const chat = await foundry.addDeployment('chat', FoundryModels.OpenAI.Gpt41);
const realtime = await foundry.addDeployment('realtime', FoundryModels.OpenAI.GptRealtime);

Both versions describe the same shape: a Foundry project plus two model deployments, one for normal chat and one for realtime voice.

Prompt agents

A prompt agent is useful when the agent does not need custom application code. You define its instructions, model deployment, and tools, and Foundry hosts the agent behavior.

In Aspire, that can be part of the AppHost:

C# AppHost

var webSearch = project.AddWebSearchTool("websearch");

var researchAgent = project.AddPromptAgent("researcher", chat,
    instructions: """
        Answer product questions. Use web search when current information is needed.
        """)
    .WithTool(webSearch);

TypeScript AppHost

const webSearch = await project.addWebSearchTool('websearch');

const researchAgent = await project.addPromptAgent(chat, 'researcher', {
    instructions: 'Answer product questions. Use web search when current information is needed.',
}).withTool(webSearch);

Both snippets create a Foundry prompt agent backed by the chat deployment and give it a Foundry-managed web search tool. There is no separate web service to write for this agent.

Hosted agents

A hosted agent is different. It is still your application code, but it is exposed through Foundry as an agent endpoint. That is useful when the agent needs custom orchestration, domain logic, framework integrations, or calls to other services.

In Aspire, the app is still modeled like any other project, with normal references to the resources it needs. The hosting choice is one line in the AppHost:

C# AppHost

var supportAgent = builder.AddProject<Projects.SupportAgent>("supportagent")
    .WithReference(chat).WaitFor(chat)
    .AsHostedAgent(project);

TypeScript AppHost

const supportAgent = await builder.addPythonApp('supportagent', './support-agent', 'support_agent/main.py')
    .withReference(chat).waitFor(chat)
    .asHostedAgent(project);

If the hosted agent needs databases, APIs, queues, or other agents, it can still use normal Aspire WithReference(...) calls. The sample stays small here because the important part is the hosting shape: this app is custom code, and Foundry can invoke it as an agent.

The agent app then exposes the Foundry Responses endpoint. In C#, that is the hosting layer around an AIAgent:

builder.Services.AddFoundryResponses(agent);

var app = builder.Build();
app.MapFoundryResponses();

That is the basic split: prompt agents are configured and hosted by Foundry; hosted agents are custom apps that Foundry can invoke as agents. Aspire keeps both in the same application graph.

The demo: one resort, many agents

AlpineAI has a real frontend, live synthetic resort data, multiple specialist agents, and two advisor experiences:

Frontend dashboard
  ├─ Chat -> Advisor Agent (.NET, Foundry hosted Responses)
  ├─ Voice -> Voice Advisor Agent (.NET, Voice Live WebSocket)
  └─ Live panels -> Data Generator (Go)

Advisor agents
  ├─ Weather Agent (Python, A2A)
  ├─ Lift Traffic Agent (.NET, A2A)
  ├─ Safety Agent (Python, A2A)
  ├─ Ski Coach Agent (Python, A2A)
  └─ Ski Researcher (Microsoft Foundry prompt agent + web search)

Each specialist has a narrow responsibility. The weather agent handles current conditions and forecasts. The lift traffic agent handles lift status and wait times. The safety agent handles risk, closures, and slope safety. The ski coach agent turns preferences and skill level into recommendations. The ski researcher is a Foundry prompt agent with web search for general skiing questions.

With those primitives in place, the larger demo is easier to read. The Aspire AppHost is where the distributed system becomes explicit. It declares Microsoft Foundry, model deployments, the prompt agent, Cosmos DB, Go and Python apps, .NET projects, the frontend, Azure Container Apps placement, and every service reference between them.

Two advisor entry points

AlpineAI has two user-facing advisor agents.

The advisor agent is the chat orchestrator. It is custom .NET code published as a Foundry hosted agent, so clients can invoke it through the Foundry Responses surface. It receives the user request, decides which specialists are relevant, invokes only those agents, and synthesizes the answer. For example, “I’m intermediate, I dislike crowds, and wind is strong. Where should I ski?” needs weather, lift traffic, safety, and ski coaching. “What is carving?” should go to the web-backed ski researcher instead.

The voice advisor agent is a custom-code agent too, but it is not published as a hosted agent. It is a .NET WebSocket service that connects browser audio to Azure AI Voice Live, uses the realtime model deployment, stores conversation state, and exposes the same specialist network to the voice experience.

Specialist agents are normal services

The other agents are application code. They need dependencies, endpoints, telemetry, and access to the data generator. Aspire models them as regular resources deployed to Azure Container Apps.

The data generator is a Go app. It produces changing resort telemetry for weather, lifts, slopes, and safety signals:

var dataGenerator = builder.AddGolangApp("datagenerator", "./data-generator")
    .WithGoModTidy()
    .WithHttpEndpoint(env: "PORT")
    .WithHttpHealthCheck("/health")
    .WithComputeEnvironment(aca);

The Python weather, safety, and ski coach agents are also Uvicorn apps. Each one references the model deployment and the data generator:

var weatherAgent = builder.AddUvicornApp("weatheragent", "./weather-agent-python", "weather_agent_python.main:app")
    .WithUv()
    .WithHttpHealthCheck("/health")
    .WithReference(deployment).WaitFor(deployment)
    .WithReference(dataGenerator).WaitFor(dataGenerator)
    .WithComputeEnvironment(aca);

The lift traffic agent is .NET, but it sits in the same graph:

var liftAgent = builder.AddProject<Projects.LiftTrafficAgent_Dotnet>("lifttrafficagent")
    .WithReference(deployment).WaitFor(deployment)
    .WithReference(dataGenerator).WaitFor(dataGenerator)
    .WithComputeEnvironment(aca);

This is where Aspire matters. The AppHost is not just a launch script. It captures the operational truth of the system: which services exist, which runtime they use, which model they depend on, which data source they call, what telemetry they emit, and where they are deployed.

Agents as tools

The specialist agents expose their capabilities over A2A. The advisor resolves them at startup and turns each remote agent into a tool with MAF:

static async Task<AIAgent> ResolveA2AAgentAsync(string serviceName)
{
    var baseUrl = Environment.GetEnvironmentVariable($"services__{serviceName}__https__0")
        ?? Environment.GetEnvironmentVariable($"services__{serviceName}__http__0")
        ?? throw new InvalidOperationException($"{serviceName} endpoint not configured.");

    var endpoint = new Uri(baseUrl);
    var httpClient = new HttpClient { BaseAddress = endpoint };
    var resolver = new A2ACardResolver(endpoint, httpClient);
    var agentCard = await resolver.GetAgentCardAsync();

    return agentCard.AsAIAgent(httpClient);
}

The Foundry prompt agent is also wrapped as an AIAgent, so the advisor can use it alongside the A2A specialists:

var skiResearcherAgentReference = new AgentReference(
    name: Environment.GetEnvironmentVariable("SKIRESEARCHER_AGENTNAME"));

var responseClient = foundryProjectClient.ProjectOpenAIClient
    .GetProjectResponsesClientForAgent(skiResearcherAgentReference);

var skiResearcherAgent = responseClient
    .AsIChatClient("gpt41")
    .AsAIAgent("ski-researcher", description: "Searches the web for skiing questions.");

Then the advisor becomes a single MAF agent with five tools:

var enableSensitiveTelemetry = bool.TryParse(
    Environment.GetEnvironmentVariable("ENABLE_SENSITIVE_TELEMETRY"),
    out var enabled) && enabled;

var agent = new AIProjectClient(new Uri(projectEndpoint), new DefaultAzureCredential())
    .GetProjectOpenAIClient()
    .GetProjectResponsesClient()
    .AsIChatClient(deploymentName)
    .AsBuilder()
    .ConfigureOptions(options => options.AllowMultipleToolCalls = true)
    .UseOpenTelemetry(
        sourceName: "Foundry.Agents",
        configure: cfg => cfg.EnableSensitiveData = enableSensitiveTelemetry)
    .Build()
    .AsAIAgent(
        name: "advisor-agent",
        instructions: "You are the Ski Resort Advisor.",
        tools:
        [
            weatherAgent.AsAIFunction(),
            liftAgent.AsAIFunction(),
            safetyAgent.AsAIFunction(),
            coachAgent.AsAIFunction(),
            skiResearcherAgent.AsAIFunction()
        ]);

This is the core pattern: specialist agents become tools. The advisor does not hard-code every data lookup. It delegates to agents that own their domains.

For building the hosted-agent apps themselves, use the official Microsoft Agent Framework hosted-agent Responses samples as the source of truth: .NET and Python.

Publishing the orchestrator as a Foundry hosted agent

In AlpineAI, the advisor is not just another local API. Aspire publishes it as a Foundry hosted agent:

var advisorAgent = builder.AddProject<Projects.AdvisorAgent_Dotnet>("advisoragent")
    .WithHttpEndpoint(targetPort: 9000)
    .WithReference(deployment).WaitFor(deployment)
    .WithReference(weatherAgent).WaitFor(weatherAgent)
    .WithReference(liftAgent).WaitFor(liftAgent)
    .WithReference(safetyAgent).WaitFor(safetyAgent)
    .WithReference(coachAgent).WaitFor(coachAgent)
    .WithReference(skiResearcher).WaitFor(skiResearcher)
    .AsHostedAgent(project);

The relevant app code is the Foundry Responses endpoint:

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddFoundryResponses(agent);

var app = builder.Build();
app.MapFoundryResponses();
app.Run();

That gives the advisor a Foundry Responses endpoint and lets Aspire add dashboard affordances for invoking it.

Chat and voice share the same agent network

The demo also includes a voice advisor. It is a .NET WebSocket service that connects browser audio to Azure AI Voice Live and gives Voice Live access to the same downstream tools:

var voiceAdvisorAgent = builder.AddProject<Projects.VoiceAdvisorAgent>("voiceadvisoragent")
    .WithReference(project).WaitFor(project)
    .WithReference(deployment).WaitFor(deployment)
    .WithReference(voiceDeployment).WaitFor(voiceDeployment)
    .WithReference(conversations).WaitFor(conversations)
    .WithReference(weatherAgent).WaitFor(weatherAgent)
    .WithReference(liftAgent).WaitFor(liftAgent)
    .WithReference(safetyAgent).WaitFor(safetyAgent)
    .WithReference(coachAgent).WaitFor(coachAgent)
    .WithReference(skiResearcher).WaitFor(skiResearcher)
    .WithComputeEnvironment(aca);

This is another place where Aspire earns its keep. The voice service needs the Foundry project, the chat model, the realtime model, Cosmos DB for conversation storage, and all downstream agents. Those dependencies are not hidden in setup scripts or copied between README files; they are represented in the AppHost.

The frontend is also part of the same graph:

builder.AddViteApp("frontend", "./frontend", "dev")
    .WithReference(advisorAgent).WaitFor(advisorAgent)
    .WithReference(voiceAdvisorAgent).WaitFor(voiceAdvisorAgent)
    .WithReference(dataGenerator).WaitFor(dataGenerator);

Now aspire run starts the frontend, data generator, chat advisor, voice advisor, specialist agents, Foundry resources, and Cosmos emulator as one system.

Observability is part of the design

Distributed agents are hard to debug without traces. You need to know which agent was called, which tool ran, how long each step took, and where failures happened.

Aspire makes that much easier because it gives the app an OpenTelemetry endpoint and a dashboard to view the traces. Instead of guessing what happened inside a multi-agent request, you can follow the request path across the frontend, advisor processing, A2A calls to specialists, Foundry model calls, and downstream HTTP calls to the data generator.

Why Aspire is the right abstraction

The AlpineAI demo is not one agent. It is a distributed application:

• Microsoft Foundry account, project, model deployments, and prompt agent.
• Go data generator.
• Python specialist agents.
• .NET specialist agent.
• .NET hosted Responses advisor.
• .NET voice WebSocket advisor.
• Cosmos DB conversation storage.
• React frontend.
• Azure Container Apps deployment environment.
• Health checks, service references, environment variables, ports, and telemetry.

Without Aspire, that becomes a pile of scripts, environment variables, Docker Compose files, deployment notes, and tribal knowledge. With Aspire, the graph is the source of truth. You can run the whole resort locally, see every resource in the dashboard, inspect logs and traces, invoke agents from the dashboard, and keep deployment configuration close to the code.

That is the bigger lesson: as agentic apps become distributed systems, they need distributed-systems tooling. Microsoft Agent Framework gives you the programming model for building agents and composing agents as tools. Microsoft Foundry gives you managed models, prompt agents, tools, hosted agents, and realtime capabilities. Aspire gives you the app model that ties everything together.

The bottom line

Complex multi-agent systems should not be treated as demos glued together by environment variables. They should be modeled as applications.

AlpineAI shows what that looks like: specialist MAF agents, a Foundry prompt agent, a hosted advisor, a voice advisor, live data, a frontend, cloud resources, and traces all described through Aspire. The result is a system that is easier to run, easier to reason about, easier to observe, and closer to how real agentic applications need to be built.

Useful links

• AlpineAI ski-resort demo repository

The post Distributed multi-agent systems with Aspire and Microsoft Agent Framework appeared first on Aspire Blog.

Hi lovely readers,

If you have spent any time online lately, you have probably seen the endless debates about which programming language you should learn next. Should it be Rust because everyone keeps saying it is the future? Should you stick with C# and .NET? Is JavaScript still worth it, or is it finally time to pick up Python because of all the AI tooling?

These are fair questions, and I love a good language debate as much as the next developer. But after spending the last couple of years watching how AI tools changed the way I actually work day to day, I have come to a slightly different conclusion. The most important language for a developer in the age of AI is not C#, JavaScript, or Rust.

It is English.

You are not writing code anymore, you are describing it

For most of my career, the gap between an idea in my head and working code was filled by me typing that code out, line by line. I knew the syntax, I knew the patterns, and the language I used to get from idea to result was C#.

That gap looks very different now. A large part of my day involves explaining what I want to an AI tool, reviewing what it gives back, and then explaining what was wrong or what I want changed. The bottleneck is no longer "do I know the syntax for this LINQ query." The bottleneck is "can I describe this problem clearly enough that something else can solve it."

That is not a coding skill. That is a communication skill.

If you ask a vague question, you get a vague answer. If you describe the wrong problem, you get a solution to a problem you do not have. The clearer you can express what you actually need, the better the result. And the language most of these tools were trained on, the language most documentation is written, the language most of the prompts and examples online use, is English.

I learned this the hard way in my second language

If you have read some of my other posts, you already know that English is not my first language. I am Dutch, and during university my teachers regularly pointed out how I would lose my train of thought halfway through a sentence. Writing clearly in a second language took me years of effort, which I learned mostly through blogging. That effort turned out to be one of the best investments I ever made, and I did not even realize it at the time.

When you work with AI tools, the quality of your output is tied directly to how clearly you can phrase things. A messy, half-finished thought gives you a messy, half-finished answer. A precise description, with the right context and the right constraints, gives you something you can actually use. The skill of taking a fuzzy idea and turning it into clear sentences is exactly the same skill I had been practicing for years without knowing how useful it would become.

So if English is not your first language either, I want to be honest with you. Yes, this puts a little extra weight on something that is already harder for us. But it is also a skill you can build, the same way you built your ability to read a stack trace or debug a null reference exception. It just takes practice.

Communication was always a huge part

Here is something that I think a lot of us already knew before AI made it impossible to ignore. The hardest parts of software development were rarely the code itself.

The hard parts were understanding what a stakeholder actually wanted instead of what they said they wanted. Writing a pull request description that your reviewer could understand without three follow-up messages. Explaining a technical decision to someone who does not write code. Leaving a comment that your future self would thank you for. Writing documentation that someone could actually follow.

All of that is language. All of that is the ability to take something complicated and make it understandable for another human being. AI did not create this skill, it just turned up the volume on how much it matters. The developers who can clearly explain a problem, give good context, and describe what "done" looks like are the ones getting the most out of these tools right now.

Reading is half of the skill

It is easy to focus only on the part where you describe what you want, but there is another half that matters just as much. You also have to read carefully.

AI tools are confident even when they are wrong. They will happily invent a method that does not exist, suggest a package that was deprecated years ago, or solve your problem in a way that quietly breaks something else. If you cannot read the answer critically and notice when something is off, you are going to have a bad time.

That critical reading is, again, a language skill. It is the ability to follow an explanation, spot the part that does not make sense, and ask a sharp follow-up question. The same way a good code reviewer reads a diff and immediately senses something is wrong, you now need to read generated answers the same way. The better you are at reading, the less likely you are to copy something into production that you did not actually understand.

Programming languages do not stop being important

I want to be clear, because I can already see the comments online. I am not saying you should stop learning programming languages, or that syntax no longer matters, or that you can ship software without understanding what the code does. You absolutely still need to understand your stack. You need to know enough to tell when an answer is nonsense, to debug the thing when it breaks at 4 PM on a Friday, and to make real decisions about architecture and trade-offs.

Programming languages are still the thing the machine runs. But English has quietly become the thing you use to get there. One does not replace the other. They sit next to each other, and right now, a lot of developers are not putting enough effort into the second one.

How to actually get better at it

The good news is that this is a skill you can practice, and you probably already have the perfect tools for it.

Write more. Write blog posts, write detailed pull request descriptions, write proper commit messages, write documentation for the thing you just built. Every time you force yourself to explain something clearly in writing, you are training the exact muscle that makes you better at working with AI.

Pay attention to your prompts. When you get a bad answer, do not just try again with the same vague request. Ask yourself what context was missing, what you assumed the tool already knew, and how you could have phrased it more precisely.

And if English is not your first language, do not let that stop you. Read in English, write in English, and let yourself be a little uncomfortable while you improve. I promise it gets easier, and it pays off in more ways than you expect.

That's a wrap!

Thanks for reading! If you have thoughts, disagree with me, or want to share your own experience, feel free to leave a comment or reach out on my socials. I am always happy to talk about this stuff.

You open a document, download it, make a quick edit, and upload it back. A few hours later, someone else edits a different copy. Now there are multiple versions, conflicting changes, and no clear source of truth.

This download edit, and reupload cycle feels normal, but it quietly breaks document processes in modern applications. For developers building React apps, the real issue isn’t how users behave. It’s that editing still happens outside the application.

The solution is Syncfusion^® React DOCX editor that keeps editing entirely inside the application, no downloads, no stray copies, no round-trip HTML conversions that break Word formatting.

In this post, you’ll learn:

• Challenges with file-based document processes (download, edit, and reupload)
• How in-browser DOCX editing works
• Key features of a React DOCX editor
• Integration basics and real-world use cases

Why file-based DOCX processes break modern apps

At first glance, file-based processes seem simple: download, edit, and upload. In practice, they introduce friction at every step.

• Version confusion
  Every download creates a new copy. Teams quickly lose track of which version is current.
• Security risks
  Files move to personal devices, emails, or external drives. Once they leave your app, control is gone.
• Formatting issues
  When documents are edited across different tools, layouts break, especially with complex tables or page structures.
• Operational overhead
  Comparing versions, merging edits, and fixing formatting takes time that should never be spent.
• Poor user experience
  Switching between tools interrupts processes and slows down simple changes.

These issues aren’t edge cases; they’re structural problems caused by file-based editing.

How in-browser DOCX editing works

The core limitation of most browser-based editors is how they handle DOCX files.

The problem with HTML-based editing

Many editors convert DOCX files to HTML, allow editing, and then rebuild the DOCX file on export.

That conversion step introduces:

• Layout inconsistencies
• Broken tables
• Lost formatting
• Pagination issues

Native DOCX editing approach

In contrast, native in-browser DOCX editing works directly with the document model.

• No format conversion: Edits apply directly to the DOCX structure.
• Page-level accuracy: Margins, headers, and pagination remain consistent.
• Reliable output: What you see during editing matches the exported file.
• Efficient handling: Large documents stay responsive with virtualization.

This architectural difference is what determines whether an editor preserves fidelity or breaks it.

Tips: Keep documents in SFDT during the drafting phase to speed up and improve efficiency. Export to DOCX at milestones: final approval, regulatory submission, or external distribution. This approach preserves fidelity at every stage without unnecessary format conversions during the active editing cycle.

Essential features for a production-ready React DOCX Editor

A usable editor isn’t just about typing text. Production applications require a combination of editing, collaboration, and control.

Collaboration

• Track changes for reviewing edits
• Inline comments and threaded discussions
• Real-time co-editing with a shared document state

Security and control

• Role-based access (view, edit, approve)
• Protected regions for sensitive sections
• Audit logs for compliance and traceability

Document management

• Autosave to prevent data loss
• Version history for rollback
• Approval processes for structured reviews

Export and integration

• Accurate DOCX export
• PDF generation for sharing or archiving
• API and webhook support for backend integration

These capabilities turn document editing into a controlled, scalable process inside your app.

Syncfusion React DOCX Editor with native in-browser editing

Our React DOCX editor is a production-ready document editing tool that directly edits documents in the UI, rather than relying on file handling.

With a native DOCX editor integrated into the app:

• Documents stay centralized
• Edits happen instantly
• Formatting remains consistent
• Users don’t leave the application

This approach replaces fragmented processes with a single, controlled editing experience.

It provides additional capabilities like:

• Native DOCX rendering: Applies Word rules directly (styles, tables, pagination) for accurate WYSIWYG output
• Framework support: Ready-to-use npm components for React, Angular, Vue, and JavaScript
• Flexible deployment: Supports cloud, on-premises, and hybrid setups with self-hosted APIs

Integrating Syncfusion DOCX Editor into a React App

The following walkthrough covers the complete setup, from installing the package to embedding a working editor into your React application.

1. Set up your React project

Use create React App or Vite to initialize your project:

npx create-react-app syncfusion-doc-editor
cd syncfusion-doc-editor

2. Install Syncfusion Document Editor

npm install @syncfusion/ej2-react-documenteditor

3. Import required Styles

Add the following to your index.css to ensure proper styling:

@import '../node_modules/@syncfusion/ej2-base/styles/material.css';
@import '../node_modules/@syncfusion/ej2-buttons/styles/material.css';
@import '../node_modules/@syncfusion/ej2-inputs/styles/material.css';
@import '../node_modules/@syncfusion/ej2-popups/styles/material.css';
@import '../node_modules/@syncfusion/ej2-lists/styles/material.css';
@import '../node_modules/@syncfusion/ej2-navigations/styles/material.css';
@import '../node_modules/@syncfusion/ej2-splitbuttons/styles/material.css';
@import '../node_modules/@syncfusion/ej2-dropdowns/styles/material.css';
@import "../node_modules/@syncfusion/ej2-documenteditor/styles/material.css";

4. Embedding the DOCX Editor component

Create a new file named DocumentEditor.js inside the src folder and add the following code:

import * as React from 'react';
import { DocumentEditorContainerComponent, Toolbar } from '@syncfusion/ej2-react-documenteditor';

DocumentEditorContainerComponent.Inject(Toolbar);

function App() {
    return (
        <DocumentEditorContainerComponent 
            id="container" 
            height={'590px'} 
            serviceUrl="https://document.syncfusion.com/web-services/docx-editor/api/documenteditor/" 
            enableToolbar={true}
        />
    );
}

export default DocumentEditor;

Note: Syncfusion uses SFDT (Syncfusion Document Text) format for efficient document rendering and editing. In the example above, we load a document using SFDT to initialize the editor.

5. Use the component in App.js

Import and use the DocumentEditor component in your App.js file:

import React from 'react';
import DocumentEditor from './DocumentEditor';

function App() {
  return (
    <div className='App'>
      <DocumentEditor />
    </div>
  );
}

export default App;

6. Run your application

Start the application using the start script.

npm start

Curious about implementing a DOCX editor in your React app? Check out the official documentation for a complete step‑by‑step integration guide and get started in minutes.

Real-world use cases

• Legal and contracts: Teams collaborate on contracts with track changes and audit logs, avoiding confusion from email-based revisions.
• Human resources: Templates stay consistent while allowing controlled edits, eliminating formatting issues in offer letters and documents.
• Healthcare and compliance: Sensitive documents remain inside secure systems with full audit trails, supporting regulatory requirements.
• Financial services: Reports stay centralized, with clear version history and controlled approvals.
• Education: Course materials maintain structure while enabling safe customization without repeated rework.

Explore the endless possibilities with Syncfusion’s outstanding React UI components.

Try It Free

Conclusion

Thank you for reading! The download, edit, and reupload cycle introduces hidden costs, version confusion, formatting drift, security gaps, and wasted time.

Moving DOCX editing into the browser addresses the root cause. Documents stay in one place, edits remain consistent, and processes become faster and easier to manage.

For React applications, in-browser DOCX editing isn’t just a convenience; it’s a shift toward more reliable, scalable document experiences.

Syncfusion DOCX Editor delivers this model for for React, Angular, Vue, and JavaScript, with the collaboration tools, compliance features, and integration flexibility that production document processes require. The result is faster editing cycles, fewer support tickets, stronger compliance posture, and document processes your users can actually trust.

Try the React DOCX Editor live demo to see its native editing in action.

Browse the documentation to check API reference, integration guides, and starter samples.

If you’re a Syncfusion user, you can download the setup from the license and downloads page. Otherwise, you can download a free 30-day trial.

You can also contact us through our support forum,  support portal, or feedback portal for queries. We are always happy to assist you!