Could be done using a middleware.

For CMS 12

var env = app.Environment.EnvironmentName;

app.Use(async (context, next) =>
{
    var originalBody = context.Response.Body;

    using var memStream = new MemoryStream();
    context.Response.Body = memStream;

    await next();

    context.Response.Body = originalBody;
    memStream.Seek(0, SeekOrigin.Begin);

    if (context.Response.ContentType?.Contains("text/html") == true)
    {
        var html = await new StreamReader(memStream).ReadToEndAsync();

        html = html.Replace(
            "<title>",
            $"<title>[{env}] "
        );

        await context.Response.WriteAsync(html);
    }
    else
    {
        await memStream.CopyToAsync(originalBody);
    }
});

To have this working for CMS 11 / .NET Framework you'd have to add an IHttpModule. I think I've made one in the past, want me to post that as well?

Thanks @eric I ended up doing an extension for IApplicationBuilder  using your code and calling from Startup.cs if the environment differs from Development and Production. Worked great!

Yes I would be interrested in the IHttpModule too  :) 

Just a heads up that processing entire body like that (both with middleware and http module) is quite heavy work.

Thanks for the great discussion so far, and thanks again to Eric for the middleware example - that’s a solid starting point!

Just to add a bit more context around this pattern and some considerations when you’re implementing it:

1. Why this works

The CMS UI in CMS 12 renders HTML that includes the browser tab <title> element.

By intercepting the response body in middleware, you can inject the environment name (e.g., Development, Integration, Production) right into the <title> before it’s sent back to the browser. That’s exactly what Eric’s middleware does: it buffers the response, rewrites the title, and then writes it back.

This is a straightforward way to visually differentiate environments in the editor interface.

2. Performance Consideration

As Johan pointed out, this approach does involve processing the entire HTML body on the response path. That’s not free performance-wise — it means reading and rewriting the HTML for each CMS UI page request. For most editor use cases it’s acceptable, but worth noting if your environment has heavy UI traffic or very large pages.

If that becomes a concern, you could optimize by:

• Only applying the rewrite on specific routes (e.g., /EPiServer/…)

• Only modifying the HTML when a certain header/cookie indicates an editor session

• Using regex to minimize string allocation instead of full ReadToEnd

3. IIS / On-Premise vs DXP

On DXP or Azure App Service, middleware is the right place to do this. On CMS 11 / .NET Framework, you’d replicate similar logic in an IHttpModule, which was Eric’s offer - if you still need that, it’s worth having here for those migrating older solutions.

4. Alternative Ideas

If you want the environment label to be more dynamic or controlled via config, you can combine this with:

• A custom config value (e.g., AppSettings:EditorTitlePrefix)

• An environment-aware setting that gets injected into Angular/React-based editor components

• A CSP header that adds a visible banner in the CMS UI via JavaScript

This avoids response body rewriting entirely, but it’s more involved.

Hope this will helps you !