Diego Gonzalez, Author at Microsoft Edge Blog

The Web Install API is ready for testing

Diego Gonzalez — Mon, 24 Nov 2025 16:55:46 +0000

We're happy to announce that the Web Install API is now ready for testing on your own site, as an origin trial in Microsoft Edge. With the Web Install API, your website can request the browser to install other web applications on the user's device, by calling the asynchronous navigator.install() function. This allows you to invoke the browser's built-in web app installation experience from your own user interface and exactly when you need it. This can help you improve the installation experience of your own app or suite of apps but can also be used for app store-like experiences. The Web Install API origin trial is available on Windows, macOS, and Linux. You can learn more about the API by reading our explainer document, checking out demos, or watching the following video: https://www.youtube.com/watch?v=WmFYlO4qln8

Test the API today by registering to the origin trial

The Web Install API origin trial is available now in Microsoft Edge starting with version 143 and running until version 148. To participate in the origin trial, and test the API on your live website, register to the origin trial. Here's how:

Go to the WebAppInstallation origin trial page, sign-in with your GitHub account and accept the terms of use.
Add your website's domain name to enable the Web Install API origin trial for that domain.
Copy the token string:
Add the following meta tag to your website's HTML code:

You can also send the origin trial token as an HTTP server response instead:
Origin-Trial: [paste the token here]

By registering to the origin trial, the users of your site will not need to enable the Web Install API locally. It will be enabled for them by Microsoft Edge automatically. Note that the earliest version of Edge where the origin trial is available is 143, which is, at the time of writing, available as Microsoft Edge Beta. Version 143 will become the next Edge stable release in early December, and the origin trial will continue running until Edge 148.

Or test the API locally only

You can also enable the Web Install API on your development device only, for local testing. To do this:

Open a new tab in Microsoft Edge and go to the edge://flags page.
Search for "Web App Installation API".
Change the flag's default value to Enabled and then restart the browser.

Let us know what you think

This is a very exciting milestone for the Web Install API. With this origin trial, we're hoping to gather early interest and feedback from the community on the API. The feedback you share with us will allow us to continue evolving the feature to better match your needs and use cases. To provide feedback, please open a new issue on our explainers GitHub repository. We welcome any comment, suggestion, and bug report you encounter while using the API, and we look forward to making web app installation much easier by building the functionality right into the web platform, thanks to your help!

Control your installed web application title

Diego Gonzalez — Wed, 05 Feb 2025 17:11:54 +0000

Starting with Microsoft Edge 134 (and Chrome 134), we're happy to announce the availability of a new HTML meta tag, , which allows developers to control the text that appears in the title bar of their installed applications. When developing a web application, giving your users a good experience is important. Across the various parts of your application's user interface, there will be many opportunities to fine-tune the experience and make it feel more polished. For installed web applications though, one of these opportunities lies in the title bar. The title bar of an app is usually represented as a horizontal bar that sits at the top of the window, and which contains the name of the application and the window control buttons. Sometimes, depending on the application, the title bar can also include contextual information, such as the name of an opened document for example. On the web platform, several options are available to you to control the information that's included in the title bar. In fact, in a previous post, we had covered how you can even hide the entire title bar and create your own custom UI by using the Window Controls Overlay API. But, if you choose to retain the default title bar, that UI element displays the text that comes from the page's

</code> HTML element, which can sometimes be a problem.

Indeed, the same <code><title></code> HTML element is what controls the text that's displayed in a browser tab, when your app is not installed. Developers generally use the <code><title></code> HTML element to put various pieces of contextual information about the state of their app. This can be, for instance, the number of unread messages, the name of the open document, or any other information about the state of the app. In addition, it's common for developers to add the name of their app in the <code><title></code>.

As an example, a TODO list application called <strong>TODO app</strong> might define an HTML title like:
<p style="text-align: center"><em style="text-align: center">My personal list - 4 tasks to do - 2 tasks done | TODO app</em></p>
When that same TODO list app is installed, it gets its own app window, and therefore, its own title bar. On Windows, the title bar of an installed web application always starts with the name of the app, taken from the manifest file, followed by a dash, and then followed by the contents of the HTML <code><title></code> element.

Taking the previous example again, once the app is installed, the following title bar content would appear:
<p style="text-align: center"><em style="text-align: center">TODO app - My personal list - 4 tasks to do - 2 tasks done | TODO app</em></p>
The repetition of the app's name is problematic here. Additionally, a browser tab and an installed application title bar are different UIs that serve different purposes, and we know that developers usually want to display different text content for when their app is displayed in a browser tab vs. when it's installed.

This is why we implemented <code><meta name="application-title"></code>, a new HTML meta tag which lets you control your installed application title bar content.

Taking the TODO list application example one more time, setting the title bar content to "TODO app - My personal list" can be achieved with this HTML code: <code><meta name='application-title' content='My personal list'></code>.

With the new <code>application-title</code> meta tag, you can now progressively enhance your web app's UX by displaying the appropriate text content whether it's installed as a standalone app or running in a tab, all without having to use JavaScript to dynamically change the app's name.

This functionality is available in Microsoft Edge starting with version 134 (and in other Chromium-based browsers). To learn more, see <a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta/name#:~:text=Other%20names-,application%2Dtitle,-%3A%20Used%20to%20customize">application-title on MDN</a> and visit our <a href="https://microsoftedge.github.io/Demos/pwa-application-title/">sample application</a> with a supporting browser (<a href="https://github.com/MicrosoftEdge/Demos/tree/main/pwa-application-title">source code</a>).

If you have any feedback, please share it with our team by going to <strong>Settings and more</strong> (<strong>...</strong>) > <strong>Help and feedback</strong> > <strong>Send feedback</strong> in Edge.
</article>
<article>
<h1>Taking control of your application’s title bar</h1>
<p>Diego Gonzalez — Tue, 14 Mar 2023 16:00:07 +0000</p>
Web technology is a common way to develop desktop applications. A growing number of apps are being built using an open technology stack based solely on web standards. These apps, or PWAs, can be installed from both the Microsoft Edge browser and the Microsoft Store. Once they are installed, they integrate with the operating system using advanced web capabilities that enable expected behaviours around sharing, file handling, and even UI refinements.

One UI aspect that is important to keep in mind is the title bar and the information it shows. Among other things, title bars are important since they can be read by screen readers, and also provide useful identifying information about the applications that are running.

More often than not, text in the title of the app is used to display badging, notifications, and other information that can be detrimental to the UX of the website and PWA. Some of these anti-patterns come from developers adapting to a lack of modern APIs in the past, like actual <a href="https://learn.microsoft.com/en-us/microsoft-edge/progressive-web-apps-chromium/how-to/notifications-badges">badging and push notifications.</a> Good UX practices involve using these modern APIs and leaving the title bar text readable and relevant.

In this article, we'll look at the different ways you can alter the title bar of your PWA. We'll also introduce a new proposal for better accessibility and navigation at the end, so read on for more.
<h2>Customize the upper part of the window</h2>
We will start by mentioning the way you can completely customize the installed application’s title bar. You can use the Window Controls Overlay API that is shipping in Chromium browsers to free the area that would previously be occupied by the title bar of the window. This API allows you to emulate advanced title bars with built-in controls like menus and other form controls, or use it to clear space for your app and give it have a more immersive feel. This is a powerful capability that requires custom work with either CSS or JavaScript.

To learn how to use this, read more about how to <a href="https://blogs.windows.com/msedgedev/2022/09/27/closing-pixel-gap-native-web-window-controls-overlay/">close a 30 pixel gap between native and web</a>. You can also use media queries to detect when the app is running with this feature enabled and layout content appropriately. The sample code below shows how you can detect this feature in your CSS.
<pre class="EnlighterJSRAW" data-enlighter-language="css">@media (display-mode: window-controls-overlay){
    // Change styles accordingly if the WCO feature is enabled
}</pre>
<a href="https://blogs.windows.com/wp-content/uploads/prod/sites/33/2023/03/Picture1.png"></a>

However, understanding how your app’s default title bar works can also be very useful to provide a good user experience.
<h2>Understanding the default title bar’s text</h2>
Title bars are important. We mentioned before how they play a role in accessibility and navigation. We can tweak how the title bar text can be customized. For this let’s first understand how the title bar text is sourced for installed web applications. Out of the box, without you having to do anything, there are 2 possible scenarios:
<ol>
 	<li>The installed web application title bar shows the name of the application.
<a href="https://blogs.windows.com/wp-content/uploads/prod/sites/33/2023/03/Picture2-1.png"></a></li>
 	<li>The installed web application title bar shows the name of the application, followed by some other text.
<a href="https://blogs.windows.com/wp-content/uploads/prod/sites/33/2023/03/Picture3-1.png"></a></li>
</ol>
To control the text in the title bar, we must understand where it is coming from. In both scenarios, the first part of the text in the title bar comes from the name member in the web application manifest file.
<pre class="EnlighterJSRAW" data-enlighter-language="css">/* manifest.json */
{
    "name": "The PWinter",
…
}</pre>
The second part of the text in the title bar, comes from the inner text of the HTML <code>title</code> tag in the document. This part is only shown if it is different from the <code>name</code> member in the manifest file, to avoid repetition.

For the images pictured above, scenario 1 and 2, the former has an html title that is the same as the name of the app in the manifest file. The title of the web page is<code> <title>The PWinter<title></code>. For this reason, only the string “The PWinter” is displayed.

The latter image (scenario 2) shows the same installed web application, but with the inner text of the page’s title tag set to “Custom colored PWA logos”. This causes the additional information to appear after a dash. In this case, title for said page would be <code><title>Custom colored PWA logos

. There is a third case, which is a slight variation of the scenario where the text in the title is different from the application's name, but starts with the application’s name. For example, if the web page’s title is The PWinter :: Custom colored PWA logos, then the installed app title bar will ignore the name of the application and append the rest of the string in the inner text of the title tag. As you can see, there are plenty of cases, and having an understanding of where the strings are sourced to compose the text that appears in the title bar of your installed web application is important to deliver the exact experience you want for your users. It can also help create a more polished feeling for your application that can delight users. Now that we know how the text in the title bar works, we have three recommendations to make sure your app’s title bar is exactly how you want your users to experience it:

Completely customize the appearance of the upper part of the window by using the Window Controls Overlay
Display your application title only.
Display the app title and additional contextual information.

Display your application title only

If you need a clean and minimal title bar that only has the title of the application, make sure that the content of the HTML title tag is the same as the name member in the manifest file. It is as easy as this.

Display your application title and additional contextual information

Another option is to display additional information in the title bar. For example, if you have an installed web application that does note-taking, word-processing, image-editing or other type of productivity task that involves files, you could set the additional information to the name of the open file. This is important as it can help your users quickly identify your application in surfaces that expose opened apps, like pressing Alt+Tab on Windows. As explained earlier, the additional contextual information comes from the content of the title tag in the current document. If you only want to do this when your application is installed, as opposed to running in a browser tab, you can use a media query. Using the display-mode media query we can identify when an installed app is running in standalone, fullscreen or minimal-UI mode. These are the display modes needed to install a Web app. standalone display mode will show the window’s title bar, and this is an indication that we can alter the content of the page’s title tag to specify relevant contextual information. To do so, we can programmatically change the title property of the active document.

let mql = window.matchMedia('(display-mode: standalone)');
if(mql.matches){
    document.title = "my new title";
}

By identifying when your installed PWA is running in standalone mode, you can update the text on the title of the document to provide relevant contextual information. Use this technique to display the title as you intend when your app is running in a browser tab, and when it is running as an installed self-contained window!

What’s next

Does using a media query seem cumbersome for quickly updating this contextual information? We are also investing in making this easier, while giving you the ability to still have fine grained control of how text displays in the title bar. Our current proposal is exposing a new subtitle field in the document, where developers could store this information for quick retrieval and update. We want to make sure this idea fit your needs, so let us know what you think. Whether you’re thinking of completely customizing the appearance and layout of the title bar space, or providing contextual information about the current open file in your web app, making sure your title bar behaves just as you envisioned is key for accessibility, navigation, and an all-round subtle detail that exudes attention to detail and best in class user experience!

Getting started with Protocol Handlers for your web app

Diego Gonzalez — Thu, 20 Jan 2022 17:01:36 +0000

Beginning with Microsoft Edge 96, web apps can now use Protocol Handlers in Microsoft Edge. This is a powerful feature that allows your installed web application (or PWA) to handle pre-set or custom protocols. Installed web applications can now register with the operating system as protocol handlers and launch when a specific protocol is invoked. Let’s dive into the feature to understand how developers can take advantage of it.

Typical use cases

Probably the most common protocol that we interact with is the http protocol. When we click on a link that uses this protocol, the system knows to open the web browser and navigate to the address that is specified. Another typical protocol is mailto which allows users to click on email addresses and open the default e-mail client. There are other pre-defined protocols but we can see how this concept of “URL protocol” is useful, since it tells the system about an identifier and how to access the identifier. Protocol handlers allow your web application to participate as the app in these use cases.

Benefits

By having the ability to register as protocol handlers, your web app has better integration with the operating system, and can be set to open specific protocols. It can even be set as a default handler, so if for example, the web app you are building is an email client, you can give your users the option for it to be the default application for creating new e-mails. Additionally, you can create custom schemes that your web app can handle by registering protocols that are prefixed with web+. This is useful if you require to handle a URL for which the set of safelisted schemes doesn’t fit the bill. Protocol handlers could be used for web app communication where one app directly invokes another and passes data via custom protocol links.

How-to

To register your installed web application as a protocol handler, you must use the protocol_handlers field in the manifest file. If the protocol_handlers field is present in the manifest, then during installation the web app will be registered as a protocol handler for the protocols specified in the collection. This field receives a collection of protocol and url pairs. The protocol specifies which scheme to register and the url tells the user agent which resource will process the URI.

Example

As an example we will look at the PWinter PWA. This is an installable web application that allows the user to create custom PWA logos by selecting 3 colors. The application defines the custom web+pwinter:// protocol handler in its manifest file.

"protocol_handlers": [
      {
        "protocol": "web+pwinter",
        "url": "index.html?colors=%s"
      }
    ]

With this in place and the web app installed on a desktop OS, you can now click on web+pwinter:// links on a website like web+pwinter://3D3D3D-5A0FC8-3D3D3D. This link represents the 3 colors that will be used by the installed web app for each letter. Note the value of the url key must also have a %s substring that will be replaced by the actual resource in the link. When clicking the link, the browser asks for permission to open the application, and then prompts you to confirm that you want to handle the protocol and the app you’d like to use for it. If you give permission, then the selected application opens with the specified content.

Feature Support

Protocol Handlers are supported in Windows, Linux and Mac, and are shipping in Microsoft Edge 96. We have contributed this work to the Chromium open-source project and the feature is now available in other Chromium based browsers too!

Related feature

This feature is similar to the JS method navigator.registerProtocolHandler(). It actually uses the same underlying steps, with the main difference being that registerProtocolHandler() is the JavaScript way of registering a website to handle protocols, while the protocol_handlers field in the manifest is the equivalent for installed web applications. On top of this, developers can specify multiple protocols without having to make repeated calls to the same method. You can learn more about Protocol Handlers with our documentation and the manifest specification. Protocol handling brings a powerful way to communicate between applications. Let us know how you are using or plan to use the feature, and any feedback you might have that can help us improve on the functionality. You can do so in the feedback tool in Microsoft Edge, or by pressing Alt+Shift+I. – Diego Gonzalez, Program Manager, Microsoft Edge