OneDrive "Convert file" HTML -> PDF stopped applying <style> block CSS today, 2026-09-04, after 1.5 years working correctly

Question

OneDrive "Convert file" HTML -> PDF stopped applying <style> block CSS today, 2026-09-04, after 1.5 years working correctly

Sebastian Velasquez-Munera 35

Summary

The OneDrive for Business "Convert file" action (HTML → PDF) has worked

reliably for approximately 1.5 years with no CSS-related issues. Today,

2026-09-04, it started intermittently failing to apply CSS rules declared

inside the <style> block in the <head> of the source HTML — while inline

styles (style="...") continue to render correctly.

This is the FIRST time this issue has occurred. It is not a known recurring

problem on our side; nothing changed in our HTML template, CSS, or flow

configuration before today.

Environment

Power Automate (Cloud Flow)
Actions: OneDrive for Business – Create file (HTML) → Convert file (to PDF) → Create file (PDF)
Trigger: Power Apps
Volume: hundreds of conversions/day
History: same HTML/CSS template in production for ~1.5 years with no prior issues

Timeline — All events on 2026-09-04

08:23 AM: PDF generated correctly, full CSS applied.
08:56 AM: Same HTML/CSS structure (only form data differs) — PDF generated with all <style> block CSS missing. Only inline styles and isolated attribute-selector rules (input[type='checkbox']:checked) were applied.
Confirmed via diff that the two source HTML files are byte-identical in <head>/<style> — only form data values (names, checkbox states, signature images) differ. This rules out the HTML/CSS as the cause.
Later: after some time, a subsequent test conversion succeeded with full styling applied, suggesting the issue had resolved.
Shortly after: ran several more test conversions with the same template. Only 1 out of several produced a correctly styled PDF; the rest again had missing <style> CSS.
As of now, the issue is intermittent and ongoing today.

Steps to Reproduce

Generate an HTML file containing a <style> block with element selectors (html, body), classes (e.g. .bg-gray-200), and attribute selectors (input[type='checkbox']:checked).
Save the HTML file via OneDrive "Create file".
Convert it to PDF via OneDrive "Convert file".
Save the resulting PDF via "Create file".
Repeat several times with the same HTML/CSS structure (only form data changes between runs) — result is inconsistent between runs.

Expected Behavior

All CSS rules declared in <style> are consistently applied in every

resulting PDF, matching how the HTML renders in a browser, and matching the

behavior this flow has had for the past 1.5 years.

Actual Behavior

Same HTML/CSS template produces correctly styled PDFs on some runs and PDFs missing all <style> block CSS on other runs, with no pattern tied to the HTML/CSS content itself (confirmed identical via diff).
Success rate today has been very low (1 correct PDF out of several test runs).

Evidence

Diff of source HTML from the 08:23 AM (good) and 08:56 AM (bad) runs: 0 differences in <head>/<style>, confirming the CSS/template is not the cause.
This matches community reports of the OneDrive/SharePoint HTML-to-PDF conversion backend having intermittent, non-deterministic rendering issues, with Microsoft having previously confirmed internal service incidents (ICM tickets) on this exact conversion path.

Impact

Business-critical safety/compliance PDF forms (work-at-height permits) are currently being generated with missing layout/branding styles.
High volume (hundreds/day) makes manual QA of every PDF impractical.
Actively affecting production today.

Priority

HIGH — first-time occurrence today, actively affecting production, very low

success rate in same-day testing.

Locked Question. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

Hendrix 2,350 Reputation points Independent Advisor

2026-09-04T21:38:39.6966667+00:00
Hi Sebastian,

Thank you for your detailed sharing.

I have tried reproducing the situation you described in my testing environment, but I cannot gather more insights into what may be causing this issue.

Therefore, for you to receive the best possible assistance in this case, I recommend reaching out to your IT administrator to create a support ticket via Microsoft 365 Admin Center > Support > Help & Support for further backend investigation.

This route ensures you can contact a technical support engineer who can perform a remote session to investigate the situation, verify the backend configurations, and run any necessary synchronization tools to resolve the problem. If the issue requires further attention, they can escalate it to a specialized team for deeper analysis.

For guidance on how to request support in the admin center, please share this link with your IT admin: Get support - Microsoft 365 admin. 

If you are unsure who your IT administrator is, you can refer to this official Microsoft guide for assistance: How do I find my Microsoft 365 admin? - Microsoft Support.

I hope this helps point you in the right direction. While I’m not able to intervene directly, guiding you to the right support team is the most effective help I can provide here.

Hope you're able to get this resolved soon.
Phalod Towsiri 10 Reputation points

2026-09-05T16:46:11.8733333+00:00

Confirming the same issue on our tenant. Same pipeline (OneDrive Create file HTML -> Convert file to PDF), started

2026-09-04/05. In our case it's not just <style> block CSS missing — the @page CSS rule controlling custom page size (non-A4/Letter) is also being ignored, causing output to fall back to A4 with content anchored top-left instead of the intended small label size. Confirmed via byte-identical HTML across before/after runs (same as your diff test) — same file, same CSS, different Convert File output.
ANZ-SVC-PowerAutomate 10 Reputation points

2026-09-07T06:00:07.7566667+00:00

We are also having simialr issue from 04/09/2026 and impacitng all the workflows. Not sur ewhat's the alterantive as Inline CSS is also not working and when this will be solved? Does anyone have any idea on any alternative ?
LW 15 Reputation points

2026-09-07T08:16:07.2833333+00:00

Facing same issue!!!! Have you found any way to resolve it?
Mroczkowski, Tomasz 5 Reputation points

2026-09-07T15:04:01.13+00:00

I have the same issue. When using the OneDrive for Business connector "Convert file" action to convert HTML to PDF, CSS styles and formatting are not being applied to the output PDF file.
Sebastian Velasquez-Munera 35 Reputation points

2026-09-07T22:09:50.32+00:00

For everyone who asked if I found a solution: not yet. It seems to be related to changes made by Microsoft, so the only options for now are to wait or replace all styles with inline CSS.
Emilio García Rodríguez 0 Reputation points

2026-09-08T08:34:36.2866667+00:00

Confirming the same issue in our tenant since September 4, 2026. Multiple production Power Automate flows using OneDrive for Business Create file HTML → Convert file to PDF are affected without any changes to the flows or HTML templates.

The generated PDFs preserve text, borders, font colors, alignment, tables, images and signatures, but all background/fill colors are removed.

We have tested CSS inside <style>, inline background-color, and the legacy bgcolor attribute. None of them restore the background colors.

The same templates generated correctly formatted PDFs before September 4. This affects safety and compliance documents generated in production.
LW 15 Reputation points

2026-09-09T09:58:46.14+00:00

It's back to normal already
ANZ-SVC-PowerAutomate 10 Reputation points

2026-10-07T06:13:57.1433333+00:00

Looks Like this Issue has started again, anyone facing the same issue again ?
Emilio Roqueta 5 Reputation points

2026-10-07T10:16:13.5133333+00:00

Same scenario here, today still not working.
Emilio García Rodríguez 0 Reputation points

2026-10-09T08:53:55.8666667+00:00

Unfortunately, the problem has returned.

The service appeared to be fixed after the September incident and worked correctly for several weeks. Now, the same unchanged production flows are once again generating PDFs without background and fill colors.

We have already confirmed that the source HTML is correct and that the failure affects CSS in <style> blocks, inline background-color declarations, and the legacy bgcolor attribute. The conversion action reports success, even though the resulting PDF is incorrectly rendered.

This recurring server-side behavior is affecting safety and compliance documentation. We need Microsoft to acknowledge the recurrence, identify the associated service incident, and provide a permanent fix or a supported workaround.

2 answers

Hendrix 2,350 Reputation points Independent Advisor

2026-09-04T21:38:39.6966667+00:00

Hi Sebastian,

Thank you for your detailed sharing.

I have tried reproducing the situation you described in my testing environment, but I cannot gather more insights into what may be causing this issue.

Therefore, for you to receive the best possible assistance in this case, I recommend reaching out to your IT administrator to create a support ticket via Microsoft 365 Admin Center > Support > Help & Support for further backend investigation.

This route ensures you can contact a technical support engineer who can perform a remote session to investigate the situation, verify the backend configurations, and run any necessary synchronization tools to resolve the problem. If the issue requires further attention, they can escalate it to a specialized team for deeper analysis.

For guidance on how to request support in the admin center, please share this link with your IT admin: Get support - Microsoft 365 admin. 

If you are unsure who your IT administrator is, you can refer to this official Microsoft guide for assistance: How do I find my Microsoft 365 admin? - Microsoft Support.

I hope this helps point you in the right direction. While I’m not able to intervene directly, guiding you to the right support team is the most effective help I can provide here.

Hope you're able to get this resolved soon.
Phalod Towsiri 10 Reputation points

2026-09-05T16:46:11.8733333+00:00

Confirming the same issue on our tenant. Same pipeline (OneDrive Create file HTML -> Convert file to PDF), started

2026-09-04/05. In our case it's not just <style> block CSS missing — the @page CSS rule controlling custom page size (non-A4/Letter) is also being ignored, causing output to fall back to A4 with content anchored top-left instead of the intended small label size. Confirmed via byte-identical HTML across before/after runs (same as your diff test) — same file, same CSS, different Convert File output.
ANZ-SVC-PowerAutomate 10 Reputation points

2026-09-07T06:00:07.7566667+00:00

We are also having simialr issue from 04/09/2026 and impacitng all the workflows. Not sur ewhat's the alterantive as Inline CSS is also not working and when this will be solved? Does anyone have any idea on any alternative ?
LW 15 Reputation points

2026-09-07T08:16:07.2833333+00:00

Facing same issue!!!! Have you found any way to resolve it?
Mroczkowski, Tomasz 5 Reputation points

2026-09-07T15:04:01.13+00:00

I have the same issue. When using the OneDrive for Business connector "Convert file" action to convert HTML to PDF, CSS styles and formatting are not being applied to the output PDF file.
Sebastian Velasquez-Munera 35 Reputation points

2026-09-07T22:09:50.32+00:00

For everyone who asked if I found a solution: not yet. It seems to be related to changes made by Microsoft, so the only options for now are to wait or replace all styles with inline CSS.
Emilio García Rodríguez 0 Reputation points

2026-09-08T08:34:36.2866667+00:00

Confirming the same issue in our tenant since September 4, 2026. Multiple production Power Automate flows using OneDrive for Business Create file HTML → Convert file to PDF are affected without any changes to the flows or HTML templates.

The generated PDFs preserve text, borders, font colors, alignment, tables, images and signatures, but all background/fill colors are removed.

We have tested CSS inside <style>, inline background-color, and the legacy bgcolor attribute. None of them restore the background colors.

The same templates generated correctly formatted PDFs before September 4. This affects safety and compliance documents generated in production.
LW 15 Reputation points

2026-09-09T09:58:46.14+00:00

It's back to normal already
ANZ-SVC-PowerAutomate 10 Reputation points

2026-10-07T06:13:57.1433333+00:00

Looks Like this Issue has started again, anyone facing the same issue again ?
Emilio Roqueta 5 Reputation points

2026-10-07T10:16:13.5133333+00:00

Same scenario here, today still not working.
Emilio García Rodríguez 0 Reputation points

2026-10-09T08:53:55.8666667+00:00

Unfortunately, the problem has returned.

The service appeared to be fixed after the September incident and worked correctly for several weeks. Now, the same unchanged production flows are once again generating PDFs without background and fill colors.

We have already confirmed that the source HTML is correct and that the failure affects CSS in <style> blocks, inline background-color declarations, and the legacy bgcolor attribute. The conversion action reports success, even though the resulting PDF is incorrectly rendered.

This recurring server-side behavior is affecting safety and compliance documentation. We need Microsoft to acknowledge the recurrence, identify the associated service incident, and provide a permanent fix or a supported workaround.

Answer 1

Hi everyone,

Since there are many users experiencing the same behavior, there is a high possibility that it could be an ongoing service degradation. However, after my research, there is no official article or announcement from Microsoft that confirms or provides information regarding this issue.

That said, I highly recommend contacting your administrator and asking them to use the "Report an issue" option within the Microsoft 365 Admin Center > Health > Service health > Overview > Report an issue to submit feedback and diagnostic information directly to Microsoft, as this may help provide additional data for investigation.

User's image

Thank you for your cooperation and understanding.

Answer 2

People might find these Reddit and Power Platform threads useful:

I checked with Co-Pilot, and off the back of the reddit thread, it suggested being explicit about what is in the rule i.e.:

@media print {

*,

html,

body,

table,

thead,

tbody,

tr,

th,

td,

div,

p,

span,

h1,

h2,

h3 {

-webkit-print-color-adjust: exact !important;

print-color-adjust: exact !important;

color-adjust: exact !important;

}

The suggested solution worked for me to fix the colour issue but not with fixing an incorrect font typeface

Greg Kalapis 0 Reputation points

2026-10-16T15:18:46.7+00:00

The method suggested in @Jennifer McKillop 's comment resolved the issue for me.

In case someone also has issues with kernering / character spacing during conversion like me, adding the below into the global css seems to work:

html {

text-rendering: geometricPrecision;

}