HTML TO PDF Conversion is not working(It was working till Friday 15th May)

(1) Share

Report

Posted on by AG-18051804-0

Hello,
So my html to pdf conversion from onedrive is not working and is giving me blank pdf.
It was working before, but suddenly it stopped working today and sending me blank pdf i saw a few things like previously it used to give different body and now it gives different , Also previously the content type was pdf now its showing html.

Categories:

Building flows

I have the same question (0)

All responses (7)

Answers (0)

Sort by

romer0 2 on at

Like (0)

Report
Copy link

Link copied!

Just to add: i'm having the same problem. A big workflow my company holds (the last one on powerautomate) got this problem.

I already transfered all other to another, most reliable, source. But, this one, as it is 100% m365, it was still here.

One more time this guys makes us go away.

great job!

Was this reply helpful? Yes No
Amardeep Raj 56 on at

Like (2)

Report
Copy link

Link copied!

Hello,

When creating a temporary HTML file before converting it to PDF, make sure to use a unique file name every time. Also, ensure the file extension passed during conversion is .pdf. This issue can sometimes happen because of caching.

I can see in the input headers:
"x-ms-apihub-cached-response": "true"

So please try using a unique temp file name and make sure the correct extension is being passed during conversion. The major issue here is that the wrong extension is being passed intermittently, which results in the response returning HTML instead of PDF content.

If the issue is resolved, click the "Mark as Answered" button on the helpful reply so others facing the same error can find the answer quickly.

Thank you

Was this reply helpful? Yes No
AG-18051804-0 8 on at

Like (0)

Report
Copy link

Link copied!

@Amardeep Raj I have tried all the things and it still did not work

Was this reply helpful? Yes No
AG-18051804-0 8 on at

Like (0)

Report
Copy link

Link copied!

@romer0 which is the other source? can you tell me

Was this reply helpful? Yes No
RH-21052003-0 2 on at

Like (0)

Report
Copy link

Link copied!

Same issue, I have a very basic four columns one row html file sitting in temp folder. I've done unique path, unique file name and it just sits as a html. Then try to email it and it comes out as just file.

Was this reply helpful? Yes No
Suggested answer

Radwan Almsora 17 on at

Like (1)

Report
Copy link

Link copied!
Hello,

You are not alone in experiencing this. This is a known regression issue caused by a silent backend update rolled out to the OneDrive for Business connector deployment ring over the May 15th, 2026 weekend.

Your screenshots provide the exact technical proof of why your PDF is suddenly appearing completely blank:

The Technical Breakdown From your Screenshots

Before (Working State): The OneDrive Convert File action correctly outputted Content-Type application/pdf and encapsulated the file stream inside a base64-encoded $content JSON object. Your subsequent Create file action read this cleanly.

Now (Broken State): The connector is incorrectly returning Content-Type: text/html, but it is pushing the raw, unencoded string binary of the PDF (starting with the %PDF-1.4 header) directly into the root body payload without encoding it. When your downstream Create file 1 action tries to parse this mismatched payload, it writes a corrupted, 0-byte, or completely blank PDF document.

Until Microsoft rolls out a hotfix to restore the native application/pdf metadata handler to the OneDrive connector, you can implement one of the following two verified community workarounds to restore your production flows immediately:

Workaround 1: Force Base64 Re-encoding (No architectural changes)

Since the Convert file action is now spitting out raw string data instead of an automated JSON object, you can manually force Power Automate to handle the raw binary string properly using expressions.

In your final Create file 1 action (where you generate the actual PDF):

Clear the current token you have in the File Content field.

Click the Expression tab and insert the following formula:

Save and test the flow. This forces the engine to re-wrap the corrupted raw text back into a healthy binary stream that SharePoint/OneDrive can read as a valid PDF.

base64ToBinary(base64(outputs('Convert_file')?['body']))

Workaround 2: Switch to the Muhimbi or Adobe PDF Connector (Enterprise Grade)

If your flow handles mission-critical documents and you cannot afford to wait for Microsoft’s standard deployment ring hotfix, the native OneDrive conversion engine is notoriously prone to these layout desync shifts.
The industry best practice for stable HTML-to-PDF rendering involves switching the single "Convert file" action to a dedicated third-party action block:

Adobe PDF Services Connector: Uses standard HTML/CSS formatting engines and does not drop style tags or alter its header schema during Microsoft platform updates.

Muhimbi PDF Converter: Handles complex CSS tables and embedded images seamlessly.

Summary / Next Steps

Please check if Workaround 1 immediately recovers your data stream. Additionally, since this is an active regression breaking standard connector contracts, please consider opening an official ticket through the Power Platform Admin Center (PPAC) referencing your precise header changes (text/html override) so the support tier can escalate it to the OneDrive Product Group immediately.

If this analysis resolves your current issue, please consider marking this as an Accepted Solution so other users flooded by this weekend's update can find the fix quickly!

Best regards,

Was this reply helpful? Yes No
Amardeep Raj 56 on at

Like (0)

Report
Copy link

Link copied!

@AG-18051804-0

Can you please send screenshots of the Create File action and the Convert File action in edit mode?

Also, could you please explain why you are using two Create File actions and which one you are converting in pdf? This will help me understand the flow better and resolve the issue more effectively.

Thanks

Was this reply helpful? Yes No