I’ve run into this issue before and discovered that the key is to adjust the response headers to prompt inline display rather than a forced download. What I ended up doing was modifying my API endpoint to set the Content-Disposition header to inline. This way, the browser receives a clear instruction and opens the PDF in a new tab if the link target or JavaScript action specifies it. I also made sure that the client side had an appropriate trigger (like an anchor tag with target=“_blank”) so that the new tab was properly activated. This approach worked seamlessly in my project.
Based on my experience, a viable solution was to change the way the file is handled on the client side. Instead of relying solely on the API, after receiving the PDF response, I convert the byte array into a Blob and create an object URL. This URL can be opened in a new tab using window.open. It effectively bypasses some of the header issues by ensuring that the browser treats the data as a stream to be displayed inline. This approach not only resolves the issue but also offers better cross-browser support, as it allows both inline viewing and proper resource handling.
In my experience, one straightforward solution involves directly returning an HttpResponseMessage from the API. I replaced the use of FileContentResult with an HttpResponseMessage, explicitly setting the Content-Disposition header to inline. This approach ensures that the browser treats the file as viewable content and opens it in a new tab. I encapsulated the PDF byte array in a ByteArrayContent and set its MIME type properly so that the PDF displays correctly in the browser. Combining this with a simple window.open call in the client code reliably met my requirements.