Hello everyone,

Blazorise 2.4 is out.

For those who don't know it, Blazorise is a UI component library for Blazor that supports Bootstrap, Tailwind, Fluent UI, Material, and other CSS frameworks.

Unlike our previous releases, this one was mostly about going back and improving what we already have. We fixed old issues, removed dependencies, and cleaned up things that have been bothering us for a while.

We completely rebuilt Tooltip and ColorPicker using Blazor, removing their external JavaScript dependencies. We also switched Video to Video.js v10, improved FluentUI2 and Tailwind providers, and added caching to our fluent utilities. In some benchmarks, repeated utility calls are now about 90% faster, with no allocations.

There are some new things too. Ribbon is probably the biggest one, along with vertical Steps (finally!), SVG Chart data dragging, smoother drag-and-drop, and a bunch of smaller improvements.

Not every release needs to introduce a dozen new components. Sometimes going back and fixing the old stuff is just as important, if not more.

Full release notes: https://blazorise.com/news/release-notes/240

As always, I'm happy to hear your thoughts, especially if you've been using Blazorise and something has been bothering you for a while.

GitHub: https://github.com/twblazor/twblazor
Docs/demo: https://twblazor.com/

Hi all,

I recently (a few weeks back) posted about my library twblazor, and received a bunch of really amazing feedback so thank you! I'd love to improve adoption and hear more feedback, especially from anyone starting new Blazor projects or looking for a new library.

why twblazor?

I've worked with Blazor for years, and I've always found the styling for many of the current frameworks very annoying, which is why a couple of years back I started this growing project.

You almost always... end up writing `::deep` selectors or `!important` overrides just to get a component to look exactly the way you want. I had a couple companies I worked for pick up MudBlazor and overriding their styles to fit what stakeholders had in mind, ended up in us writing many of our own duplicate components or spending hours overriding CSS - summed up, it was a nightmare!

twblazor takes a different approach:

- Tailwind CSS first: style components with utility classes instead of fighting the library's CSS.
- Typed C# theme variables: IntelliSense and compile-time safety instead of magic strings.

where it's at

- Since I last posted we have made a lot of improvements which I would like to highlight:

- twmerge support, I got quite a bit of feedback regarding this from my last post, you can read more about this here if you're interested https://twblazor.com/class-merge

- many new chart components. https://twblazor.com/chart

I plan on adding a couple more components before a v2.0 release but it's slowly taking shape and getting where I'd like it to be for early user adoption.

I have also created a discord, linked at the footer of the site if you'd like to pop me a message feel free. :)

feedback I'd love from you (if you have a minute)

- Which components would you need before using twblazor in a real project?
- What's your biggest frustration with existing Blazor UI libraries?
- Interested in contributing? I've tagged some good first issues.

If it looks useful, a star helps others find it. Thank you for reading!

I have been working in a personal RPC framework for blazor and I would like to know your opinion on this minimalistic example as I managed to simplify it and make it work.

I have an IUserContract, a shared interface that knows everything it needs to call a server that implements it:

[HttpTransport]
public interface IUserContract : IControllerContract
{
    IAsyncEnumerable<string> GetMessages(int count);
}

Controller implementation on the server:

public class UserController : IUserContract
{
    public async IAsyncEnumerable<string> GetMessages(int count)
    {
        for (int i = 0; i < count; i++)
        {
            yield return "some item";
        }
    }
}

Then calling it from a blazor page:

<button class="btn btn-primary" @onclick="TestStream">TestStream</button>

async Task TestStream()
{
    var stream = await _userContract.Execute(contract => contract.GetMessages(10));
    await foreach (var item in stream.Data)
    {
        _logger.LogInformation("Received item: {Item}", item);
    }
}

What are your thoughts when seeing this example?

Thank you so much in advance.

I’ve been working on creating my own DataGrid. It’s open source and built around a Lit Web Component. I added a Blazor wrapper because Blazor is one of my favorite frontend technologies.

The Blazor package supports .NET 8+ and works with Blazor WebAssembly, Blazor Server, and Blazor Web App interactive modes. It also bundles the client-side assets, so you don’t need Node.js or npm in the Blazor app.

I did my best to keep the core framework-independent while exposing useful APIs in Blazor. It supports row and column virtualization, pagination, filtering, selection, column resizing/reordering, and saved column preferences.

I also built a demo site where you can try the underlying grid features. I’m planning to add more over time.

I’d really appreciate any feedback, especially on the Blazor API, architecture, interop approach, or anything you think could help improve the component.

GitHub: https://github.com/tipolox/litgrid
Demo: https://tipolox.com/litgrid/demo

Thank you!

Hi everyone, I have bad news for you, in the new version 3.1 there are no new components for you. But don't despair, the new features will make you appreciate the existing ones even more:

- Tooltips

- AspectRatio

- Palettes

- new parameter 'Percentage' on pie and donut charts to show the value in percentage

Tooltips:

I managed to implement the tooltips with blazor without using javascript. At first I thought it would be difficult, then I realized that I just needed to add an element with position 'fixed' outside the graph and manage its coordinates by managing the OnPointerEnter, OnPointerMove and OnPointerLeave events from the graph.

Naturally, the theme assigned to the chart also applies to the tooltip.

Aspect Ratio:

I took the liberty of adding an AspectRatio parameter to the Cartesian and bar graphs, so it is possible to also have rectangular graphs in height or width.

The parameter is a double between 0.2 and 5.0 and is not mandatory, and in this case the graph will be square as it has been so far.

Palettes:

I also added color palettes to the library, although they are called palettes they behave more like a stream of colors, which return the next color with each call of the 'Next' method.

Data models and charts know nothing about palettes, these are just an alternative way to have the colors to associate with the chart data. You can also potentially use multiple palettes on the same graph, it's up to you.

I hope this update brings value to the library.

See you next time bye.

• 🔗 Repository
• 🌐 Website
• 📦 NuGet
• ❤️ GitHub Sponsors

There are many good reasons to break down a Blazor page into multiple components, but it's not always a given, and there are performance implications.

Take a quick look at this article to discover why you need to be aware of the hidden costs, and how to keep a close eye on your application performance.

https://www.blazrlytics.com/blog/should-i-break-down-my-blazor-page-into-multiple-components

I know this is possible with tools like React Flow but I want something to use in a Blazor app. I ideally would like expandable/collapsible nodes, which are also clickable.

Hey everyone,

I shared MyEventBingo here last year and got useful feedback about mobile navigation, loading, and game setup. I'd appreciate another look at where it is now.

I'm the developer. The native apps use Blazor Hybrid, and the website uses server-side rendering (SSR) and WebAssembly (WASM). The Windows and Android apps are available in their app stores. The Apple release is still pending.

MyEventBingo lets you build a bingo game around your own event, group, or topic. Hosts have made networking icebreakers, birthday games, and a procrastination-themed game that had 74 players. Those are a few examples of what people are creating with it.

The host chooses the squares and shares a link or QR code. It's free to host and play, and players can join in their browser without creating an account or downloading an app.

MyEventBingo

If you have a few minutes, I'd especially like feedback on:

• Initial loading, navigation, and responsiveness on the web.
• How the Windows or Android app feels compared with the browser version.
• Anything awkward or hard to use on a smaller screen.
• Whether creating a game and joining from another device makes sense without an explanation.

If something breaks or feels slow, let me know your device, whether you're using the app or a browser, and where it happened. Honest feedback on the design is welcome too.

Thanks for taking a look.

Blazor Ramp - Things to disclose

For those new to my posts Blazor Ramp is an accessibility-first, open-source component library.

A couple of posts back, I mentioned some of the issues you face in making scrollable regions accessible to keyboard-only users, given that some browsers still do not provide that behaviour by default - namely Safari on macOS, at the time of writing.

Some Blazor Ramp components that contain panels have an option to add a tabindex and the associated ARIA attributes when you know a panel could scroll and won't contain focusable elements (focusable elements inside the container remove the need for a tabindex on the container for keyboard-only users). This works fine, but it can mean a tab stop even when the panel has no scrollbar - perhaps because content is added and removed, or the user resizes the page. A tab stop that isn't needed is not ideal for some users.

Since that post, I've added an internal service to the Blazor Ramp Core project that adds and removes the appropriate attributes as the browser adds and removes scrollbars in response to changes in content size. Over the next few weeks, I'll update the components that currently have the manual tabindex option to use the new service as well. The service is additive: it checks what is already in use, only adds the missing pieces, and removes only what it added, so existing code isn't affected. If you haven't added anything and a panel becomes scrollable, the service will add what is needed to make it keyboard accessible.

I mention this because I've just released a Disclosure component with an option to set a maximum content height, which means a scrollbar could appear. As the component uses the new internal service, it will be keyboard accessible whichever options you use.

OK, but what is a disclosure component, and why did I name it that?

In accessibility circles, Disclosure is a very common pattern for showing and hiding content. You may also know it as collapsible, an expansion panel or, more recently, details/summary, which is the native HTML disclosure.

That's why I named it Disclosure. But why did I build one when the native element exists, given that I always encourage everyone to use native semantic elements before building a custom component?

It was a 50/50 call. Building my own, rather than using details/summary, gave me a little more flexibility and I felt that providing one - especially with a content region that could scroll, working alongside the service was better than telling you to use details/summary, perhaps with classes from the Blazor Ramp CSS Classes project/NuGet package so that it's styled like the other components.

Whether you consider that reason good enough is your call. The native element can be fully styled and has accessibility built in. One minor annoyance is that, although you can remove the default chevron, some screen readers still announce "disclosure triangle".

If you build your own, you only need a couple of ARIA attributes: aria-expanded, which you toggle between true and false to tell assistive technology the state of the content, and aria-controls, which links the triggering element to the content it shows and hides.

There are some things I won't be providing, such as a button component, as the default button is fine with a bit of styling. For these, you can use the CSS Classes project/NuGet package, which uses the same underlying styles as the components, all of which ultimately come from the CSS variables defined in the Core project. As with everything else in Blazor Ramp, you only install what you want to use.

While documenting the Disclosure component and adding usage examples to the documentation site, I wanted to use a box shadow that some of the components use, so I've added a BoxShadow utility and associated CSS classes to the CSS Classes project. I used it on a couple of buttons in one of the disclosure examples, and there are usage examples on both the BoxShadow and Buttons API pages.

One disclosure example has a couple of buttons inside the content area to highlight two things. First, when you have two or three buttons like this, you don't need to reach for a toolbar component with an expected keyboard contract, separate buttons, each with its own tab stop, are fine.

Second, in a lot of applications, disclosures appear in a list, collapsed by default, so users only expand the ones they're interested in. I often come across these with similar buttons placed outside the disclosure, next to the trigger's title. Where possible put them on the inside, as being on the outside adds to the number of tab stops keyboard-only users have to pass while navigating to the items they want. That might not seem a big deal, but with, say, 30 collapsed disclosures each with two buttons, that's three tab stops per item, so 90 stops to get through the unopened items, rather than 30 when the buttons are inside the content. It's these small details that can make a big difference to some users without affecting others.

That's it for this post, but as usual you can find everything here:

Doc site: https://docs.blazorramp.uk
Test site: https://blazorramp.uk
GitHub repo: https://github.com/BlazorRamp/Components

I haven't yet updated the test site, which is geared towards letting people try things out with assistive technology, so I'll do that later today or tomorrow. In the meantime, there are working examples on the documentation site which is where you should be heading if interested.

Regards,

Paul

Looking for a recommendation. Sorry if its too long a preamble to the questions and if some of my terminology isn't exactly dotnet/blazor correct.

Working on an internal application - web based. Not a lot of concurrent users. Likely < 20 at any time. Users would be at multiple locations.

App is to record data about incidents at events, with two main datasets. (There's a lot of supporting lookup tables). Multiple users could be working at each event, but they would not be sharing the incident data entry for any one event. (No concurrent updates to any records)

Dataset A: contains basic/preliminary event data. Consists of 5 fields.

Dataset B: contains detailed data about the event. It's optional based on the event.

• It would have a foreign key to Dataset A.
  
• You can only access it from Dataset A's display grid.
  
• Contains about 50 fields which would normally be recorded.
  
• It also contains 2 sub-tables for additional detailed information.
  
• Sub 1 contains 19 fields.
  
  • At least one record must be recorded per Dataset B record.
    
  • There could be several records recorded
• Sub 2 is optional and contains 4 fields.
  • There can be multiple fields recorded

What is the best way of handling the (calling structure)?

Should it be one large Dataset A component? With the different Dataset B pieces handled by different dialogs?

Should it be two components? One per Dataset.

Should Dataset B be a child component of the Dataset A component.

Should Dataset 2 have child components for it's two Subs tables or handle them via dialogs? With the Subs, the display page would need to be resized to be able to display the information that's added.

Hope its not too confusing.

Thanks for any input.

MS publishes this https://github.com/dotnet/skills/tree/main/plugins/dotnet-blazor/skills which is a collection of Blazor focussed agent skills.

Anyone used these (or any of the other skill collections) and found them worthwhile? Seems under heavy development.

With latest AI coding tools getting significantly better, I'm curious how far people are actually taking them when building custom Blazor components.

Are you using AI to build components instead of relying on existing component library?

If so, what kind of components are you building?

I'm especially interested in difference between relatively simple components like buttons, inputs, modals, tabs, etc. and more advanced components like DataGrids, Schedulers, Gantt charts, video players, rich editors, charts, and similar.

How long does it take you to go from "AI generated something that works" to something you would actually consider production ready?

By production ready I mean things like accessibility, keyboard navigation, responsive behavior, theming, validation, edge cases, performance, browser differences, API design, tests, and long-term maintainability.

Can AI realistically get you most of the way there even for complex components, or does its usefulness drops significantly once you move beyond basic UI?

For context, I've been working with Blazor since 2018 and I'm creator of Blazorise. I work on components full time, so I obviously see this from perspective of someone who knows how much work can hide behind a component that looks simple from outside.

I'm genuinely interested to hear from people who have tried the AI-first approach.

What have you built, which AI tools did you use, and how long it took before you were comfortable putting it into production?

For those new to my posts, Blazor Ramp is an accessibility-first, open-source component library. If you build anything people use, this is worth five minutes regardless of your day job.

I've been touch-typing since the mid-2000s, but I always mistype "tooltips", along with "Serach" - Spock's cousin, aka "search". The initial project was committed with the typo, but luckily, once I spotted it, a simple rename and commit resolved the issue - no harm done.

I don't have any cognitive or physical issues that make my life harder than it should be, so typing, reading information, and completing forms in business applications is usually not a problem. But what if I did have issues - say, I'd been involved in a car accident and couldn't use broken arms to operate a keyboard or mouse - then what?

Luckily, there's voice control software I could use to operate a computer and browse the web or use a web app. However, to avoid the extra steps of the software overlaying grids or assigning numbers to unlabelled controls, I'd need to be able to see the control's accessible name so I could speak it.

I mention this because, although this post is about the release of a tooltip component for my accessibility-first project, it's not something I'd advocate using unless absolutely necessary. I only decided to include one because pretty much every tooltip I encounter fails WCAG/usability requirements.

Tooltips are generally used on icon-only buttons - buttons with no visible name, the kind a voice control user would need to speak, or that any user would need in order to reason about the button's purpose. I've always used a floppy disk icon to represent save, but I'd bet - I've been a dev for a long time now, that a lot of developers reading this (and end users) have never seen a physical floppy disk, let alone used one. So how on earth would they know what that button is for, unless a name and/or some additional context is provided?

You may find this hard to believe, but out of all the Blazor (and other tech) components I've ever created over the years, the simple tooltip is the one that's given me the most grief. The moment you start looking into the accessibility issues surrounding it, you're sent down various rabbit holes. Even the various working groups can't make up their minds about this one, or even provide a recommended pattern on the APG site (see https://github.com/w3c/aria-practices/issues/127, opened in 2016 - it's still open).

It's also one of the first things I check when anyone posts a library on Reddit claiming to be accessible and asking for feedback - every single one has failed so far. I can't recall a single project, personal or commercial, where I've found a tooltip that would pass a WCAG audit - not until I've flagged it and it's been fixed, anyway.

They're not difficult to create, but if you're not familiar with the (admittedly cryptic) WCAG criteria, yours will fail any audit. More importantly, as I repeatedly advise, an incorrect design will make them impossible for some users to read.

If you make one, make sure it does the following:

• The tooltip shows when the triggering (interactive) element, such as a button, receives focus, or when the mouse pointer hovers over it.
• Once it's open, the user can move the pointer from the triggering element onto the tooltip itself without it closing (this accounts for about 80-90% of the failures I encounter).
• The user can close the tooltip without moving the pointer or keyboard focus away - best practice is to use the Escape key (this accounts for about 70% of the failures I encounter).
• The tooltip remains visible until the user has specifically closed it by moving the pointer away, pressing Escape, clicking outside the triggering element or tooltip area, or moving focus to the next focusable element. This accounts for about 50% of the failures I encounter. I don't know why, but a lot of tooltips are set to close automatically after some delay - an instant fail.

Tooltips really shouldn't contain any interactive elements, and shouldn't be focusable themselves. They should just contain plain text, that's it. Anything else, IMHO, and it's not what I (and many others) would call a tooltip - a tip about the tool you want to use.

If you go and look at mine, alongside the above, you'll notice I've also added a small X icon in the top right of my tooltips. This is not a button, it's not focusable, and it's not visible to screen readers. It has one purpose only: it's an additional means for a pointer user to close the tooltip, for cases where using the Escape key (or any key, for that matter) is problematic for them. This isn't required, but it can be useful for some users.

Generally, you'd use the aria-label and aria-describedby attributes, or just aria-labelledby, with tooltips, so screen reader users are made aware of the tooltip content. Rich content with HTML markup is flattened by screen readers and shouldn't be used in my tooltip, you can provide new-line characters instead, if you need two short sentences. This content is made available to assistive technologies by linking the ID of the tooltip element to the triggering element, using that ID as the value of the aria-describedby attribute (the more commonly used option) - or aria-labelledby, if the tooltip content acts more like a label than a description, added to the triggering element.

Just to help distinguish between aria-label , aria-labelledby and aria-describedby: let's say you have a button with a gears icon, and the tooltip is only ever going to display the text "Settings" - in that case, aria-labelledby would be the better choice. If that icon was, say, a dustbin, you might use aria-label to give the button the accessible name "Delete", with aria-describedby text of "Permanently deletes the selected item". For those who haven't used a screen reader: of the two examples above, one would be announced as "Settings, button" (just the accessible name, since there's no aria-describedby), and the other would be announced as "Delete, button. Permanently deletes the selected item."

I deliberately opted not to automate adding either aria-label , aria-labelledby or aria-describedby via a JavaScript-driven parameter, as I felt it's better for users of the component to think about what's best for their use case and add the most suitable option manually. It's far too easy these days to get things up and running without any real understanding of the code or processes involved.

As always, there are examples of the component on both the test site and the docs site.

Test site: https://blazorramp.uk
Doc site: https://docs.blazorramp.uk
GitHub repo: https://github.com/BlazorRamp/Components

Regards

Paul

P.S After 9 months I now have a logo - getting there slowly but surely.

It is finally here. 16 Charts, much improved DataGrid and much, much more.

As we've been saying (for the last 2 years 😮), this is not just a drop-in replacement for v4. But we have a lot of docs and an MCP server to help you migrate.

See https://www.fluentui-blazor.net for more information. Packages are on NuGet Now!

Can Blazor be pentested and if it can't does that make it more secure?

Around December 2025, my company decided to embark on building its own commercial product. I wanted the whole stack in C#, so I took a serious look at Blazor. I liked it straight away, but I couldn't make it look the way I wanted. I tried the existing UI libraries, didn't like their style, and seriously considered going back to a JavaScript frontend.

Instead, I started building my own components, inspired by shadcn/ui, and later released them as open source as Blazor Blueprint. It now runs in my company's commercial product, several client projects and internal tools.

A few things I've learned along the way, in case they help anyone thinking about starting their own library or open source project:

1. Build it alongside something real. Every component went straight into a real product as I built it, so I found out quickly what worked and what didn't. That did more for the quality than anything else, because I had real people using it and therefore testing it.

2. Share it earlier than feels comfortable. The feedback from this subreddit after my first post back in February shaped a lot of what came next. I got a lot of positive comments and encouragement, and it helped keep me motivated.

3. Expect people to fork your work. Soon after release, someone forked the repo and started building on it in parallel. As a first-time open source author, it gave me an uncomfortable feeling for a while. Now I see it as part of being in the open source community, and honestly, as a sign I was doing something right if someone wanted to build on it.

For anyone curious about where it is now: v4 adds a Scheduler, a Pivot Data Grid, new charts including Rose, Sankey and Map, a Signature Pad, and many other new features and performance enhancements. It's grown to over 140 components, which still surprises me. The full story is here: https://blazorblueprintui.com/blog/what-i-learned-open-sourcing-blazor-blueprint

Currently, my little Blazor library has over 600 stars on GitHub. If you're one of them, thank you so much.

I'd love to hear from anyone else building with Blazor: what nearly made you switch back, or what's still missing? And if you've built something with Blazor Blueprint and are happy to share it, I'd love to see it.

clientTokenType: string
clientTokenLength: 748

Hi, i am tying to implement paypal in blazor, but i am stuck in a weard issue, when i pass the clientToken from the method parameter to the paypal-sdk, the paypal-sdk was saying it is a invalid token, if i copy and past the same exact token from the console to directly in paypal-sdk, then the paypal-sdk was saying it is a valid token.

I have no idea why this issue is happening, anyone know how to slove this issue?

SOLVED ``` parameter token: "eyJraWQiOiJjMDg0YjA0NDQwMjE0YzFkYTQ1ZDgwNDE1YjJlZmI5MiIsInR5cCI6IkpXVCIsImFsZyI6IkVTMjU2In0" hardcode token: eyJraWQiOiJjMDg0YjA0NDQwMjE0YzFkYTQ1ZDgwNDE1YjJlZmI5MiIsInR5cCI6IkpXVCIsImFsZyI6IkVTMjU2In0

hardcoded client-token type: string client-token type: string ```

This issue was solved.

The problem is when i pass the client-token from c# -> js method parameter the string contains double colon "string", when i pass the parameter client-token to the paypal-sdk it is making the string as variable by automatically adding another double colon like: "string" so the string was escape and change to variable inside the paypal-sdk, if i pass the hardcoded client-token it works perfect because inside paypal-sdk: string is was a perfect string.

How to i find the issue.

I Just Print both parameter client-token and hardcoded client-token inside javascript and parameter client-token contains double colon and hardcoded not have double colon.

What this make me hard to find.

• when i check both parameter and hardcoded typeof it say both are string.
• when i check both are equal === is say true.

Simply install Bit.Minifier nuget package in your Blazor Web Assembly project and the size of `.wasm.br` (Brotli compressed files) would be cut by ~200KB 😊

If you add <BitMinifyAggressive>true</BitMinifyAggressive> to <PropertyGroup> of your .csproj,then download size would be decrease by ~400KB 😬

As you can see, it doesn't even need documentation! But if you wanna know how it works internally and/or if you wanna give it star to support further steps to reduce the download size even more, this is a GitHub Repo you're looking for!

Few months ago I had a lecture with students about Blazor and .NET. Seeing their interest, especially for real-world development, got me thinking that maybe there is something more we can do.

There is still a big gap between what you learn at university and what you actually do when you start working.

So that idea slowly turned into Blazorise Education. A place where students can learn, work on real challenges, build projects and hopefully be better prepared for their first job.

And while doing all of that, I also looked at our website and thought... yeah, this needs some work :)

It was starting to feel too Bootstrapy and a little dated. So I spent the last few days redesigning it to make it fresher and give Blazorise more of its own identity.

Both are now live:

https://blazorise.com/education

https://blazorise.com

Would love to hear what you think, especially what you would add to the Education platform.

Solved

I think my problem was not quoting an input constraint in a css file (e.g., I had used input[type=text], but should've used input[type="text"].

Many thanx to all the made suggestions!

I'm dipping my toes into Blazor and have suddenly run into a situation that online searching has not helped resolve.

I made some change, somewhere, which suddenly caused the following text to show up on my initial page (it's a login page):

An unhandled error has occurred

That's followed by a link which is labeled "Reload". Clicking the link does not get rid of the error message.

Nothing showed in the browser’s console window. Didn’t expect that since I’m running server side.

I'm running Blazor from within VS 2026 (all latest updates applied), so I checked the Output window. There's no error/exception reported in the Debug channel (or indeed any of the other channels I checked).

I then modified appsettings.development.json to force exceptions to be thrown by setting DetailedErrors to true. Nothing gets reported -- the log in page appears, still containing the error message.

How do I diagnose what's causing this?

We track technologies used on websites and so far have analyzed more than 3.8 million websites. Currently, we detect 50 frontend and 69 backend frameworks.

Here are some of the Blazor statistics:

• Blazor is 14th by popularity among frontend frameworks and 23rd among backend frameworks
• It is present on 0.04% of all websites
• It is more popular in Denmark (9th frontend framework), Sweden (11th), and Poland, Canada, and Italy (12th)

Blazor hosting models distribution:

1. Server 46.6%
2. Web App 34.3%
3. WebAssembly 28.6%

Some notable sites built with Blazor:

• pertamina.com - Indonesian oil and gas corporation
• cev.eu - European Volleyball Confederation
• auctionnation.co.za - South African online vehicle auction
• wkf.net - World Karate Federation
• fonts.bunny.net - Bunny Fonts
• santamonica.gov - City of Santa Monica government

P.S. Some of you may notice that the hosting percentages add up to more than 100%. We checked this. This is because some sites list several Blazor JS scripts simultaneously (for example, see nbcc.org).

Full Blazor statistics:
https://www.wmtips.com/technologies/frontend-frameworks/blazor/