This information relates to a pre-release product that may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.
This article describes how to use Blazor's globalization and localization features based on:
The Accept-Language header, which is set by the browser based on a user's language preferences in browser settings.
A culture set by the app not based on the value of the Accept-Language header. The setting can be static for all users or dynamic based on app logic. When the setting is based on the user's preference, the setting is usually saved for reload on future visits.
For additional general information, see the following resources:
Often, the terms language and culture are used interchangeably when dealing with globalization and localization concepts.
In this article, language refers to selections made by a user in their browser's settings. The user's language selections are submitted in browser requests in the Accept-Language header. Browser settings usually use the word "language" in the UI.
Culture pertains to members of .NET and Blazor API. For example, a user's request can include the Accept-Language header specifying a language from the user's perspective, but the app ultimately sets the CurrentCulture ("culture") property from the language that the user requested. API usually uses the word "culture" in its member names.
The guidance in this article doesn't cover setting the page's HTML language attribute (<html lang="...">), which accessiblity tools use. You can set the value statically by assigning a language to the lang attribute of the <html> tag or to document.documentElement.lang in JavaScript. You can dynamically set the value of document.documentElement.lang with JS interop.
CultureInfo.InvariantCulture is used for the following field types (<input type="{TYPE}" />, where the {TYPE} placeholder is the type):
date
number
The preceding field types:
Are displayed using their appropriate browser-based formatting rules.
Can't contain free-form text.
Provide user interaction characteristics based on the browser's implementation.
Blazor provides built-in support to render values in the current culture. Therefore, specifying a culture with @bind:culture isn't recommended when using the date and number field types.
The following field types have specific formatting requirements and aren't supported by all of the major browsers, so they aren't supported by Blazor:
datetime-local
month
week
For current browser support of the preceding types, see Can I use.
.NET globalization and International Components for Unicode (ICU) support (Blazor WebAssembly)
Blazor WebAssembly uses a reduced globalization API and set of built-in International Components for Unicode (ICU) locales. For more information, see .NET globalization and ICU: ICU on WebAssembly.
To load a custom ICU data file to control the app's locales, see WASM Globalization Icu. Currently, manually building the custom ICU data file is required. .NET tooling to ease the process of creating the file is planned for .NET 10 in November, 2025.
Blazor WebAssembly uses a reduced globalization API and set of built-in International Components for Unicode (ICU) locales. For more information, see .NET globalization and ICU: ICU on WebAssembly.
Loading a custom subset of locales in a Blazor WebAssembly app is supported in .NET 8 or later. For more information, access this section for an 8.0 or later version of this article.
Invariant globalization
This section only applies to client-side Blazor scenarios.
If the app doesn't require localization, configure the app to support the invariant culture, which is generally based on United States English (en-US). Using invariant globalization reduces the app's download size and results in faster app startup. Set the InvariantGlobalization property to true in the app's project file (.csproj):
This section only applies to client-side Blazor scenarios.
Adopting invariant globalization only results in using non-localized timezone names. To trim timezone code and data, which reduces the app's download size and results in faster app startup, apply the <InvariantTimezone> MSBuild property with a value of true in the app's project file:
<BlazorEnableTimeZoneSupport> overrides an earlier <InvariantTimezone> setting. We recommend removing the <BlazorEnableTimeZoneSupport> setting.
A data file is included to make timezone information correct. If the app doesn't require this feature, consider disabling it by setting the <BlazorEnableTimeZoneSupport> MSBuild property to false in the app's project file:
The following CultureExample1 component can be used to demonstrate Blazor globalization and localization concepts covered by this article.
CultureExample1.razor:
@page "/culture-example-1"
@using System.Globalization
<h1>Culture Example 1</h1>
<ul>
<li><b>CurrentCulture</b>: @CultureInfo.CurrentCulture</li>
<li><b>CurrentUICulture</b>: @CultureInfo.CurrentUICulture</li>
</ul>
<h2>Rendered values</h2>
<ul>
<li><b>Date</b>: @dt</li>
<li><b>Number</b>: @number.ToString("N2")</li>
</ul>
<h2><code><input></code> elements that don't set a <code>type</code></h2>
<p>
The following <code><input></code> elements use
<code>CultureInfo.CurrentCulture</code>.
</p>
<ul>
<li><label><b>Date:</b> <input @bind="dt" /></label></li>
<li><label><b>Number:</b> <input @bind="number" /></label></li>
</ul>
<h2><code><input></code> elements that set a <code>type</code></h2>
<p>
The following <code><input></code> elements use
<code>CultureInfo.InvariantCulture</code>.
</p>
<ul>
<li><label><b>Date:</b> <input type="date" @bind="dt" /></label></li>
<li><label><b>Number:</b> <input type="number" @bind="number" /></label></li>
</ul>
@code {
private DateTime dt = DateTime.Now;
private double number = 1999.69;
}
The number string format (N2) in the preceding example (.ToString("N2")) is a standard .NET numeric format specifier. The N2 format is supported for all numeric types, includes a group separator, and renders up to two decimal places.
Optionally, add a menu item to the navigation in the NavMenu component (NavMenu.razor) for the CultureExample1 component.
Dynamically set the culture from the Accept-Language header
The Accept-Language header is set by the browser and controlled by the user's language preferences in browser settings. In browser settings, a user sets one or more preferred languages in order of preference. The order of preference is used by the browser to set quality values (q, 0-1) for each language in the header. The following example specifies United States English, English, and Costa Rican Spanish with a preference for United States English or English:
Accept-Language: en-US,en;q=0.9,es-CR;q=0.8
The app's culture is set by matching the first requested language that matches a supported culture of the app.
In client-side development, set the BlazorWebAssemblyLoadAllGlobalizationData property to true in the client-side app's project file (.csproj):
Add the following line to the Program file where services are registered:
builder.Services.AddLocalization();
In server-side development, specify the app's supported cultures before any middleware that might check the request culture. Generally, place Request Localization Middleware immediately before calling MapRazorComponents. The following example configures supported cultures for United States English and Costa Rican Spanish:
In server-side development, specify the app's supported cultures immediately after Routing Middleware (UseRouting) is added to the processing pipeline. The following example configures supported cultures for United States English and Costa Rican Spanish:
For information on ordering the Localization Middleware in the middleware pipeline of the Program file, see ASP.NET Core Middleware.
Use the CultureExample1 component shown in the Demonstration component section to study how globalization works. Issue a request with United States English (en-US). Switch to Costa Rican Spanish (es-CR) in the browser's language settings. Request the webpage again.
Note
Some browsers force you to use the default language setting for both requests and the browser's own UI settings. This can make changing the language back to one that you understand difficult because all of the setting UI screens might end up in a language that you can't read. A browser such as Opera is a good choice for testing because it permits you to set a default language for webpage requests but leave the browser's settings UI in your language.
When the culture is United States English (en-US), the rendered component uses month/day date formatting (6/7), 12-hour time (AM/PM), and comma separators in numbers with a dot for the decimal value (1,999.69):
Date: 6/7/2021 6:45:22 AM
Number: 1,999.69
When the culture is Costa Rican Spanish (es-CR), the rendered component uses day/month date formatting (7/6), 24-hour time, and period separators in numbers with a comma for the decimal value (1.999,69):
Date: 7/6/2021 6:49:38
Number: 1.999,69
Statically set the client-side culture
Set the BlazorWebAssemblyLoadAllGlobalizationData property to true in the app's project file (.csproj):
The Intermediate Language (IL) Linker configuration for client-side rendering strips out internationalization information except for locales explicitly requested. For more information, see Configure the Linker for ASP.NET Core Blazor.
The app's culture can be set in JavaScript when Blazor starts with the applicationCulture Blazor start option. The following example configures the app to launch using the United States English (en-US) culture.
In the preceding example, the {BLAZOR SCRIPT} placeholder is the Blazor script path and file name. For the location of the script, see ASP.NET Core Blazor project structure.
Add the following <script> block after Blazor's <script> tag and before the closing </body> tag:
Use the CultureExample1 component shown in the Demonstration component section to study how globalization works. Issue a request with United States English (en-US). Switch to Costa Rican Spanish (es-CR) in the browser's language settings. Request the webpage again. When the requested language is Costa Rican Spanish, the app's culture remains United States English (en-US).
Specify the static culture in the Program file before any middleware that might check the request culture. Generally, place Request Localization Middleware immediately before MapRazorComponents. The following example configures United States English:
Specify the static culture in the Program file immediately after Routing Middleware (UseRouting) is added to the processing pipeline. The following example configures United States English:
Specify the static culture in Startup.Configure (Startup.cs) immediately after Routing Middleware is added to the processing pipeline. The following example configures United States English:
For information on ordering the Localization Middleware in the middleware pipeline of Startup.Configure, see ASP.NET Core Middleware.
Use the CultureExample1 component shown in the Demonstration component section to study how globalization works. Issue a request with United States English (en-US). Switch to Costa Rican Spanish (es-CR) in the browser's language settings. Request the webpage again. When the requested language is Costa Rican Spanish, the app's culture remains United States English (en-US).
Dynamically set the client-side culture by user preference
Examples of locations where an app might store a user's preference include in browser local storage (common for client-side scenarios), in a localization cookie or database (common for server-side scenarios), or in an external service attached to an external database and accessed by a web API. The following example demonstrates how to use browser local storage.
The app's culture for client-side rendering is set using the Blazor framework's API. A user's culture selection can be persisted in browser local storage.
Provide JS functions after Blazor's <script> tag to get and set the user's culture selection with browser local storage:
using System.Globalization;
using Microsoft.JSInterop;
Remove the following line:
- await builder.Build().RunAsync();
Replace the preceding line with the following code. The code adds Blazor's localization service to the app's service collection with AddLocalization and uses JS interop to call into JS and retrieve the user's culture selection from local storage. If local storage doesn't contain a culture for the user, the code sets a default value of United States English (en-US).
builder.Services.AddLocalization();
var host = builder.Build();
const string defaultCulture = "en-US";
var js = host.Services.GetRequiredService<IJSRuntime>();
var result = await js.InvokeAsync<string>("blazorCulture.get");
var culture = CultureInfo.GetCultureInfo(result ?? defaultCulture);
if (result == null)
{
await js.InvokeVoidAsync("blazorCulture.set", defaultCulture);
}
CultureInfo.DefaultThreadCurrentCulture = culture;
CultureInfo.DefaultThreadCurrentUICulture = culture;
await host.RunAsync();
Use the CultureExample1 component shown in the Demonstration component section to study how the preceding example works.
Dynamically set the server-side culture by user preference
Examples of locations where an app might store a user's preference include in browser local storage (common for client-side scenarios), in a localization cookie or database (common for server-side scenarios), or in an external service attached to an external database and accessed by a web API. The following example demonstrates how to use a localization cookie.
Note
The following example assumes that the app adopts global interactivity by specifying the interactive server-side rendering (interactive SSR) on the Routes component in the App component (Components/App.razor):
<Routes @rendermode="InteractiveServer" />
If the app adopts per-page/component interactivity, see the remarks at the end of this section to modify the render modes of the example's components.
To provide UI to allow a user to select a culture, use a redirect-based approach with a localization cookie. The app persists the user's selected culture via a redirect to a controller. The controller sets the user's selected culture into a cookie and redirects the user back to the original URI. The process is similar to what happens in a web app when a user attempts to access a secure resource, where the user is redirected to a sign-in page and then redirected back to the original resource.
Controllers/CultureController.cs:
using Microsoft.AspNetCore.Localization;
using Microsoft.AspNetCore.Mvc;
[Route("[controller]/[action]")]
public class CultureController : Controller
{
public IActionResult Set(string culture, string redirectUri)
{
if (culture != null)
{
HttpContext.Response.Cookies.Append(
CookieRequestCultureProvider.DefaultCookieName,
CookieRequestCultureProvider.MakeCookieValue(
new RequestCulture(culture, culture)));
}
return LocalRedirect(redirectUri);
}
}
The following CultureSelector component shows how to call the Set method of the CultureController with the new culture. The component is placed in the Shared folder for use throughout the app.
CultureSelector.razor:
@using System.Globalization
@inject IJSRuntime JS
@inject NavigationManager Navigation
<p>
<label>
Select your locale:
<select @bind="selectedCulture" @bind:after="ApplySelectedCultureAsync">
@foreach (var culture in supportedCultures)
{
<option value="@culture">@culture.DisplayName</option>
}
</select>
</label>
</p>
@code
{
private CultureInfo[] supportedCultures = new[]
{
new CultureInfo("en-US"),
new CultureInfo("es-CR"),
};
private CultureInfo? selectedCulture;
protected override void OnInitialized()
{
selectedCulture = CultureInfo.CurrentCulture;
}
private async Task ApplySelectedCultureAsync()
{
if (CultureInfo.CurrentCulture != selectedCulture)
{
var uri = new Uri(Navigation.Uri)
.GetComponents(UriComponents.PathAndQuery, UriFormat.Unescaped);
var cultureEscaped = Uri.EscapeDataString(selectedCulture.Name);
var uriEscaped = Uri.EscapeDataString(uri);
Navigation.NavigateTo(
$"Culture/Set?culture={cultureEscaped}&redirectUri={uriEscaped}",
forceLoad: true);
}
}
}
@using System.Globalization
@inject IJSRuntime JS
@inject NavigationManager Navigation
<p>
<label>
Select your locale:
<select value="@selectedCulture" @onchange="HandleSelectedCultureChanged">
@foreach (var culture in supportedCultures)
{
<option value="@culture">@culture.DisplayName</option>
}
</select>
</label>
</p>
@code
{
private CultureInfo[] supportedCultures = new[]
{
new CultureInfo("en-US"),
new CultureInfo("es-CR"),
};
private CultureInfo? selectedCulture;
protected override void OnInitialized()
{
selectedCulture = CultureInfo.CurrentCulture;
}
private async Task HandleSelectedCultureChanged(ChangeEventArgs args)
{
selectedCulture = CultureInfo.GetCultureInfo((string)args.Value!);
if (CultureInfo.CurrentCulture != selectedCulture)
{
var uri = new Uri(Navigation.Uri)
.GetComponents(UriComponents.PathAndQuery, UriFormat.Unescaped);
var cultureEscaped = Uri.EscapeDataString(selectedCulture.Name);
var uriEscaped = Uri.EscapeDataString(uri);
Navigation.NavigateTo(
$"Culture/Set?culture={cultureEscaped}&redirectUri={uriEscaped}",
forceLoad: true);
}
}
}
Add the CultureSelector component to the MainLayout component. Place the following markup inside the closing </main> tag in the Components/Layout/MainLayout.razor file:
Add the CultureSelector component to the MainLayout component. Place the following markup inside the closing </main> tag in the Shared/MainLayout.razor file:
Use the CultureExample1 component shown in the Demonstration component section to study how the preceding example works.
The preceding example assumes that the app adopts global interactivity by specifying the Interactive Server render mode on the Routes component in the App component (Components/App.razor):
<Routes @rendermode="InteractiveServer" />
If the app adopts per-page/component interactivity, make the following changes:
Add the Interactive Server render mode to the top of the CultureExample1 component file (Components/Pages/CultureExample1.razor):
@rendermode InteractiveServer
In the app's main layout (Components/Layout/MainLayout.razor), apply the Interactive Server render mode to the CultureSelector component:
Dynamically set the culture in a Blazor Web App by user preference
This section applies to Blazor Web Apps that adopt Auto (Server and WebAssembly) interactivity.
Examples of locations where an app might store a user's preference include in browser local storage (common for client-side scenarios), in a localization cookie or database (common for server-side scenarios), both local storage and a localization cookie (Blazor Web Apps with server and WebAssembly components), or in an external service attached to an external database and accessed by a web API. The following example demonstrates how to use browser local storage for client-side rendered (CSR) components and a localization cookie for server-side rendered (SSR) components.
using System.Globalization;
using Microsoft.JSInterop;
Remove the following line:
- await builder.Build().RunAsync();
Replace the preceding line with the following code. The code adds Blazor's localization service to the app's service collection with AddLocalization and uses JS interop to call into JS and retrieve the user's culture selection from local storage. If local storage doesn't contain a culture for the user, the code sets a default value of United States English (en-US).
builder.Services.AddLocalization();
var host = builder.Build();
const string defaultCulture = "en-US";
var js = host.Services.GetRequiredService<IJSRuntime>();
var result = await js.InvokeAsync<string>("blazorCulture.get");
var culture = CultureInfo.GetCultureInfo(result ?? defaultCulture);
if (result == null)
{
await js.InvokeVoidAsync("blazorCulture.set", defaultCulture);
}
CultureInfo.DefaultThreadCurrentCulture = culture;
CultureInfo.DefaultThreadCurrentUICulture = culture;
await host.RunAsync();
Add the following CultureSelector component to the .Client project.
The component adopts the following approaches to work for either SSR or CSR components:
The display name of each available culture in the dropdown list is provided by a dictionary because client-side globalization data include localized text of culture display names that server-side globalization data provides. For example, server-side localization displays English (United States) when en-US is the culture and Ingles () when a different culture is used. Because localization of the culture display names isn't available with Blazor WebAssembly globalization, the display name for United States English on the client for any loaded culture is just en-US. Using a custom dictionary permits the component to at least display full English culture names.
When user changes the culture, JS interop sets the culture in local browser storage and a controller action updates the localization cookie with the culture. The controller is added to the app later in the Server project updates section.
The app's culture for client-side rendering is set using the Blazor framework's API. A user's culture selection can be persisted in browser local storage for CSR components.
After the Blazor's <script> tag, provide JS functions to get and set the user's culture selection with browser local storage:
To allow a user to select a culture for SSR components, use a redirect-based approach with a localization cookie. The app persists the user's selected culture via a redirect to a controller. The controller sets the user's selected culture into a cookie and redirects the user back to the original URI. The process is similar to what happens in a web app when a user attempts to access a secure resource, where the user is redirected to a sign-in page and then redirected back to the original resource.
Controllers/CultureController.cs:
using Microsoft.AspNetCore.Localization;
using Microsoft.AspNetCore.Mvc;
[Route("[controller]/[action]")]
public class CultureController : Controller
{
public IActionResult Set(string culture, string redirectUri)
{
if (culture != null)
{
HttpContext.Response.Cookies.Append(
CookieRequestCultureProvider.DefaultCookieName,
CookieRequestCultureProvider.MakeCookieValue(
new RequestCulture(culture, culture)));
}
return LocalRedirect(redirectUri);
}
}
Add the CultureSelector component to the MainLayout component. Place the following markup inside the closing </main> tag in the Components/Layout/MainLayout.razor file:
Specify the app's default and supported cultures in the Program file. The following example configures supported cultures for United States English and Costa Rican Spanish.
builder.Services.AddLocalization();
Place Request Localization Middleware before any middleware that might check the request culture. Generally, place the middleware immediately before calling MapRazorComponents:
Immediately after Routing Middleware (UseRouting) is added to the processing pipeline:
var supportedCultures = new[] { "en-US", "es-CR" };
var localizationOptions = new RequestLocalizationOptions()
.SetDefaultCulture(supportedCultures[0])
.AddSupportedCultures(supportedCultures)
.AddSupportedUICultures(supportedCultures);
app.UseRequestLocalization(localizationOptions);
For information on ordering the Localization Middleware in the middleware pipeline, see ASP.NET Core Middleware.
Specify the app's default and supported cultures in Startup.Configure (Startup.cs). The following example configures supported cultures for United States English and Costa Rican Spanish.
In Startup.ConfigureServices (Startup.cs):
services.AddLocalization();
In Startup.Configure immediately after Routing Middleware (UseRouting) is added to the processing pipeline:
var supportedCultures = new[] { "en-US", "es-CR" };
var localizationOptions = new RequestLocalizationOptions()
.SetDefaultCulture(supportedCultures[0])
.AddSupportedCultures(supportedCultures)
.AddSupportedUICultures(supportedCultures);
app.UseRequestLocalization(localizationOptions);
For information on ordering the Localization Middleware in the middleware pipeline of Startup.Configure, see ASP.NET Core Middleware.
If the app should localize resources based on storing a user's culture setting, use a localization culture cookie. Use of a cookie ensures that the WebSocket connection can correctly propagate the culture. If localization schemes are based on the URL path or query string, the scheme might not be able to work with WebSockets, thus fail to persist the culture. Therefore, the recommended approach is to use a localization culture cookie. See the Dynamically set the server-side culture by user preference section of this article to see an example Razor expression that persists the user's culture selection.
Example of localized resources
The example of localized resources in this section works with the prior examples in this article where the app's supported cultures are English (en) as a default locale and Spanish (es) as a user-selectable or browser-specified alternate locale.
Create a resource file for each locale. In the following example, resources are created for a Greeting string in English and Spanish:
English (en): Hello, World!
Spanish (es): ¡Hola, Mundo!
Note
The following resource file can be added in Visual Studio by right-clicking the Pages folder and selecting Add > New Item > Resources File. Name the file CultureExample2.resx. When the editor appears, provide data for a new entry. Set the Name to Greeting and Value to Hello, World!. Save the file.
If using Visual Studio Code, we recommend installing Tim Heuer's ResX Viewer and Editor. Add an empty CultureExample2.resx file to the Pages folder. The extension automatically takes over managing the file in the UI. Select the Add New Resource button. Follow the instructions to add an entry for Greeting (key), Hello, World! (value), and None (comment). Save the file. If you close and re-open the file, you can see the Greeting resource.
Tim Heuer's ResX Viewer and Editor isn't owned or maintained by Microsoft and isn't covered by any Microsoft Support Agreement or license.
The following demonstrates a typical resource file. You can manually place resource files into the app's Pages folder if you prefer not to use built-in tooling with an integrated development environment (IDE), such as Visual Studio's built-in resource file editor or Visual Studio Code with an extension for creating and editing resource files.
The following resource file can be added in Visual Studio by right-clicking the Pages folder and selecting Add > New Item > Resources File. Name the file CultureExample2.es.resx. When the editor appears, provide data for a new entry. Set the Name to Greeting and Value to ¡Hola, Mundo!. Save the file.
If using Visual Studio Code, we recommend installing Tim Heuer's ResX Viewer and Editor. Add an empty CultureExample2.resx file to the Pages folder. The extension automatically takes over managing the file in the UI. Select the Add New Resource button. Follow the instructions to add an entry for Greeting (key), ¡Hola, Mundo! (value), and None (comment). Save the file. If you close and re-open the file, you can see the Greeting resource.
The following demonstrates a typical resource file. You can manually place resource files into the app's Pages folder if you prefer not to use built-in tooling with an integrated development environment (IDE), such as Visual Studio's built-in resource file editor or Visual Studio Code with an extension for creating and editing resource files.
The following component demonstrates the use of the localized Greeting string with IStringLocalizer<T>. The Razor markup @Loc["Greeting"] in the following example localizes the string keyed to the Greeting value, which is set in the preceding resource files.
Optionally, add a menu item for the CultureExample2 component to the navigation in the NavMenu component (NavMenu.razor).
WebAssembly culture provider reference source
To further understand how the Blazor framework processes localization, see the WebAssemblyCultureProvider class in the ASP.NET Core reference source.
Note
Documentation links to .NET reference source usually load the repository's default branch, which represents the current development for the next release of .NET. To select a tag for a specific release, use the Switch branches or tags dropdown list. For more information, see How to select a version tag of ASP.NET Core source code (dotnet/AspNetCore.Docs #26205).
Shared resources
To create localization shared resources, adopt the following approach.
Create a dummy class with an arbitrary class name. In the following example:
The app uses the BlazorSample namespace, and localization assets use the BlazorSample.Localization namespace.
The dummy class is named SharedResource.
The class file is placed in a Localization folder at the root of the app.
Localization/SharedResource.cs:
namespace BlazorSample.Localization;
public class SharedResource
{
}
Create the shared resource files with a Build Action of Embedded resource. In the following example:
The files are placed in the Localization folder with the dummy SharedResource class (Localization/SharedResource.cs).
Name the resource files to match the name of the dummy class. The following example files include a default localization file and a file for Spanish (es) localization.
To reference the dummy class for an injected IStringLocalizer<T> in a Razor component, either place an @using directive for the localization namespace or include the localization namespace in the dummy class reference. In the following examples:
The first example states the Localization namespace for the SharedResource dummy class with an @using directive.
The second example states the SharedResource dummy class's namespace explicitly.
In a Razor component, use either of the following approaches:
@using Localization
@inject IStringLocalizer<SharedResource> Loc
@inject IStringLocalizer<Localization.SharedResource> Loc
Location override using "Sensors" pane in developer tools
When using the location override using the Sensors pane in Google Chrome or Microsoft Edge developer tools, the fallback language is reset after prerendering. Avoid setting the language using the Sensors pane when testing. Set the language using the browser's language settings.
The source for this content can be found on GitHub, where you can also create and review issues and pull requests. For more information, see our contributor guide.
ASP.NET Core feedback
ASP.NET Core is an open source project. Select a link to provide feedback:
Learn how to create a graphical user interface in a Blazor web app by creating and assembling Blazor components. Access data and share it for display on multiple pages within your app.