I also faced the same issue with Browsershot and custom Urdu fonts. I tried several solutions, including absolute paths, waiting for network idle, and different @font-face configurations, but none of them worked consistently.

What finally worked for me was embedding the font directly as a Base64 data URI instead of loading it from a file path. This avoids Chrome's file access restrictions and allows the font to be embedded properly in the generated PDF without using --disable-web-security.

Example:

@php $fontPath = public_path('admin_assets/assets/urdu/NotoNastaliqUrdu.ttf'); $fontData = base64_encode(file_get_contents($fontPath)); @endphp

< style > @font-face { font-family: 'NotoNastaliqUrdu-Regular'; src: url('data:font/ttf;base64,{{ $fontData }}') format('truetype'); font-weight: normal; font-style: normal; }

body, .urdu-font { font-family: 'NotoNastaliqUrdu-Regular', serif; } < /style >

After switching to Base64-embedded fonts, the font was correctly rendered and embedded in the PDF without requiring --disable-web-security.