[▲ Vercel Community](/) · [Categories](/categories) · [Latest](/latest) · [Top](/top) · [Live](/live) [Help](/c/help/9) # UTF-8 headers are causing errors 294 views · 3 likes · 10 posts Dmitry Ishkov (@therusskiy) · 2025-05-19 Hello, I am getting the following error in Vercel logs: `Vercel Runtime Malformed Response Header Error: Header 'cf-ipcity: LuleÃ¥' contains non-ASCII characters.`. I can't stop this header from being passed into vercel request headers, so looking for solutions. I don't think UTF-8 in header values is something too uncommon. Even Vercel docs mention that UTF-8 is fine: https://vercel.com/docs/errors/MALFORMED_REQUEST_HEADER > 1. Validate UTF-8 encoding: Confirm that all request headers, especially cookie values, are valid UTF-8 strings. Non-UTF-8 characters in headers, particularly in the cookie header, often cause this error Currently my Next.js does 2 things: 1. it serves the frontend 2. it rewrites some requests to get results from another service (which needs these headers). Given UTF-8 headers are common, I think it's safe to assume it's a bug on Vercel side, but until it's fixed, how do I go around and patch it on my side? Thank you. Jacob Paris (@jacobparis) · 2025-05-20 It does look like we're inconsistent in rejecting non-ASCII while documenting UTF-8 is ok, I've passed this along to the team In the meantime, you may be able to intercept this with middleware, which should run before the Vercel Runtime error fires. Can you try looking for that header and either deleting it or encoding it into ASCII? https://nextjs.org/docs/app/building-your-application/routing/middleware#setting-headers Jacob Paris (@jacobparis) · 2025-05-20 It looks like this header is actually malformed, in UTF-8 it should be `Luleå` and the problematic `LuleÃ¥` is ISO-8859-1. You should be able to rewrite it using middleware Dmitry Ishkov (@therusskiy) · 2025-05-20 @jacobparis I am a bit confused, would that error not happen before it reaches middleware? The header that causes the bug is a part of request to Vercel, not a response. Jacob Paris (@jacobparis) · 2025-05-20 · ♥ 1 Middleware runs on the CDN edge before requests hit the Vercel datacenters, so this should work. If not, let me know and I'll escalate internally for a different fix Dmitry Ishkov (@therusskiy) · 2025-05-20 · ♥ 1 @jacobparis okay, in the meantime I actually came up with a different workaround so now this header comes in a different format before it reaches Vercel, but let's assume this is going to work for whoever stumbles on this issue. thank you, Jacob Jacob Paris (@jacobparis) · 2025-05-20 Awesome, glad that's working for you! If you don't mind, our Firewall product team is interested in any use-cases you have where you need CF in front of Vercel. Anything we can't do within Vercel infra is a product gap we need to close, so if you could share a little more about what you're doing I can pass that along and we'll get it on the roadmap Dmitry Ishkov (@therusskiy) · 2025-05-24 @jacobparis a few things, I guess first of all - price, I find price on Vercel for network traffic and images high and unpredictable, so prefer to put a CDN like Cloudflare in front of all the assets, it's solvable by using a separate CDN domain (though images are buggy and still use the same domain even if assetPrefix is specified, had to write a custom imageLoader). Shohei Maeda (@smaeda-ks) · 2026-01-20 · ♥ 1 :waving_hand: Hi @therusskiy Regarding the original issue, we’re aware of this long-standing Vercel platform constraint and are currently rolling out a change to eliminate it entirely. Once this is fully rolled out (ETA: by the end of this week if everything goes well), you can include non-ASCII characters in response headers. And if Vercel Functions runtime finds non-ASCII characters, it will encode them accordingly (percent-encode, RFC 3986) instead of throwing 500 Shohei Maeda (@smaeda-ks) · 2026-01-22 :waving_hand: @therusskiy This has been rolled out to all Hobby/Pro teams on Vercel. You can redeploy and verify the change. Thanks