DEV Community: Igor

How to Embed a PDF on a Website: HTML, iframe and Flipbooks

Igor — Sat, 31 Oct 2026 11:53:17 +0000

To embed a PDF on a website, point an iframe at the file's URL and give it a height. Keep a separate link below it so visitors can open the document outside the embedded viewer.

For a product catalog, also check the pages with small print and decide how you will replace the file when prices change. Those details usually matter more than the embed code.

Disclosure: This article was prepared for WebViewPDF. The hosted example uses its public demo catalog.

Embed a PDF in HTML with an iframe

Upload your PDF to your website, then use its URL as the iframe source:

<iframe
  class="pdf-viewer"
  src="/files/catalog.pdf"
  title="Product catalog"
  loading="lazy"
></iframe>

<p>
  <a href="/files/catalog.pdf">Open the PDF separately</a>
</p>

Set the dimensions in CSS:

.pdf-viewer {
  display: block;
  width: 100%;
  height: clamp(28rem, 75vh, 56rem);
  border: 0;
}

Replace /files/catalog.pdf with your file's address. This relative path assumes the PDF is hosted on the same website.

The title labels the frame for assistive technology. The height gives the document room to display; width: 100% fits the frame to its container. Lazy loading is useful below the fold. Remove it if the PDF is the first thing visitors should see.

The browser supplies the PDF controls. Their appearance and behavior can vary, so keep the separate link even if the embed works in your browser.

You can use this without a paid viewer or CMS plugin. You still need somewhere to host the file.

Use object for fallback content

An object element lets you put a link inside the embed as fallback HTML:

<object
  class="pdf-viewer"
  data="/files/catalog.pdf"
  type="application/pdf"
  aria-label="Product catalog"
>
  <p>
    The embedded preview is unavailable.
    <a href="/files/catalog.pdf">Open the PDF</a>.
  </p>
</object>

<p>
  <a href="/files/catalog.pdf">Open the PDF separately</a>
</p>

Use the same CSS. The link outside the object remains available if a browser fails to show the fallback properly.

For an occasional brochure or form, native embedding may be all you need. A recurring catalog can need more: search across pages, reading statistics, or a new edition behind the existing link.

Embed a catalog with a hosted flipbook

With a hosted flipbook, the iframe points to a reader page instead of the raw PDF. The provider handles document processing and the viewer interface; you depend on its service and plan limits.

Here is the Quiet Form demo embedded on the WebViewPDF homepage:

The embedded catalog, open at pages 2–3.

Open the live catalog demo

The reader URL can be used in an iframe:

<iframe
  class="pdf-viewer"
  src="https://read.webviewpdf.com/v/01a1309f-80ea-711e-aa47-62a7270af7fb"
  title="Quiet Form — Furniture & Design Collection"
  loading="lazy"
  allowfullscreen
></iframe>

<p>
  <a href="https://read.webviewpdf.com/v/01a1309f-80ea-711e-aa47-62a7270af7fb">
    Open the catalog separately
  </a>
</p>

Reuse the .pdf-viewer CSS above. This address opens the public demo. To display your own catalog, upload your PDF, wait for processing, and copy the embed code or reader URL for that publication.

Pages 6–7 opened in the separate reader: the sofa on the left, dimensions and finishes on the right.

Two details are worth checking with your own document:

Search needs text. In the demo, searching for “sofa” returns matching pages. Selecting page 6 opens the product spread shown above. WebViewPDF's search requires a PDF text layer; a scan needs OCR before upload.

The actual search results for “sofa”, with page 6 selected.

Updates should preserve the publication. In WebViewPDF, upload a new version of the existing publication to retain its reader link and embed code. Creating a new publication is a separate operation. For a printed QR code or a catalog embedded on several sites, keeping that address matters.

If you need to build custom application controls yourself, a JavaScript viewer such as PDF.js is another route. You then maintain that integration rather than relying on a hosted reader.

When an embedded PDF does not display

Blank frame

First, open the PDF or reader URL in a private browser window. Check that it opens without your administrator login and does not return a 404 or an HTML error page.

If it works directly but fails in the iframe, check the browser console. The embedded page may restrict framing through Content-Security-Policy: frame-ancestors or X-Frame-Options. Your own page's CSP may also block the frame origin. Follow the supported embedding configuration for the server or provider involved.

Download instead of preview

Inspect the response headers. Content-Disposition: attachment requests a download. Browser settings and PDF support also affect the result; changing the iframe markup may not fix it.

Works on desktop, fails on mobile

Some mobile browsers handle raw PDF embeds differently. Keep the separate link and test another viewer if inline reading is essential.

Also distinguish a blank viewer from an unreadable document. A frame that fits the screen does not reflow a PDF. Open a page with small specifications on a real phone and check zooming, scrolling and text size.

The CMS removes the code

Some editors and hosting plans strip iframe or script markup. Use the platform's supported HTML or embed block, then check the saved page. Support for iframes does not necessarily include permission to run an external script.

Before you put it on a client site

Open the finished page while signed out. Try a desktop browser and a real phone, follow a link inside the document, and check keyboard navigation and the separate PDF link. For catalogs, search for an actual product name or part number.

If the document will be updated regularly, replace it once and reopen the original page. That is the easiest time to catch a workflow that generates a new URL for every edition.

Embedding is not copy protection: hiding a download button does not secure a public PDF. It also does not put the PDF's text into the surrounding HTML. Keep essential product descriptions and navigation on the webpage when readers need them there.

References

TensorRT Was Fast. My 1080p RTSP Pipeline Wasn't.

Igor — Fri, 30 Oct 2026 10:48:25 +0000

I was troubleshooting low FPS in a TensorRT-based RTSP video analytics pipeline on a customer's server. The input was a 1920×1080 stream at 25 FPS, running on an NVIDIA GeForce RTX 5070 Ti. The pose model already used TensorRT, but the application was processing only 8–10 FPS.

Inference was accelerated. The video pipeline wasn't.

After changing how frames moved through the application, I measured 24.64 processed FPS against the same 25 FPS source. That measurement was taken before the OCR queue; it was not a benchmark of end-to-end OCR or video delivery latency.

I didn't replace the pose model. I changed the data path around it.

Why My RTSP + TensorRT Pipeline Was Stuck at 8–10 FPS

The application did more than pose detection. It decoded RTSP video, detected and tracked people, extracted torso regions for OCR, checked safety-related events, and generated an RTSP output stream.

The original path was roughly:

RTSP → OpenCV/FFmpeg → CPU frame
     → GPU inference → CPU-side processing
     → OCR → output

The TensorRT engine could execute on the GPU, but full frames still crossed the CPU/GPU boundary too often. Optimizing inference alone wasn't going to solve that.

A 1920×1080 RGB frame contains 6,220,800 bytes, or about 6.2 MB. One full-frame transfer at 25 FPS amounts to approximately 156 MB/s of image payload in one direction. This is a size calculation, not a measured PCIe bandwidth figure from the server.

Bandwidth wasn't the only concern. Intermediate buffers, format conversions, and synchronization can also add time. I needed to examine the frame's route through the application, not just the model's execution time.

Optimizing the RTSP GPU Pipeline with NVDEC and CUDA

The revised path was:

RTSP
  ↓
PyNvVideoCodec / NVDEC
  ↓
CUDA-resident frame
  ↓
GPU resize, letterbox, normalization
  ↓
Direct TensorRT inference
  ↓
GPU postprocessing and coordinate mapping
  ↓
Small metadata transfer for CPU tracking
  ↓
GPU torso ROI extraction
  ↓
OCR queue
  ↓
Downstream processing / RTSP output

Decode directly into GPU-accessible memory

I switched the decoding path to PyNvVideoCodec / NVDEC. This allowed decoded frames to remain in GPU-accessible memory instead of becoming CPU images that would then need to be uploaded for inference.

NVDEC doesn't make an entire application zero-copy by itself. The formats and buffers used by the next stages still matter. The useful change here was removing an unnecessary full-frame detour through host memory.

Keep preprocessing on the GPU

Resize, letterboxing, and normalization ran on the GPU. That let the pipeline prepare TensorRT input without routinely copying the full-resolution frame back to the CPU.

These operations aren't necessarily expensive individually. The problem is what happens when each stage creates another buffer or forces a transfer before the next stage can run.

Use direct TensorRT execution

I replaced the higher-level inference path with direct TensorRT execution using execute_async_v3().

That gave me explicit control over device buffers and execution. It wasn't the function name that made the pipeline faster: memory layout, buffer lifetime, and synchronization still had to be handled correctly. The benefit was being able to avoid work that the earlier path performed around inference.

Transfer tracking metadata, not full frames

The pose model returned person bounding boxes and 17 body keypoints. Postprocessing and coordinate mapping stayed on the GPU.

Tracking still used CPU-side information, but only compact detection metadata needed to cross to the CPU. Sending an entire 1080p frame just to update tracking coordinates would have defeated much of the optimization.

Prepare OCR regions on the GPU

The pose keypoints defined torso regions for OCR. I extracted those ROIs on the GPU rather than copying the complete image to the CPU just to crop it.

Those ROIs then entered the OCR queue. This boundary matters when interpreting the performance number below.

I didn't try to move every part of the application to CUDA. I kept large pixel buffers on the GPU and moved smaller data when a CPU-side stage actually needed it.

Benchmark Results: 24.64 FPS on RTX 5070 Ti

The cover image is a frame from the tested pipeline, with tracking IDs and FPS counters overlaid.

Measurement	Value
Video source	1920×1080 RTSP
Source frame rate	25 FPS
GPU	NVIDIA GeForce RTX 5070 Ti
Before optimization	8–10 processed FPS
After optimization	24.64 processed FPS
Output FPS counter	25.00 FPS
Processing measurement boundary	Before OCR queue

The overlay showed:

PROCESSED: 24.64
OUTPUT:    25.00
SOURCE:    25

Compared with the original 8–10 FPS range, 24.64 FPS is about 2.5–3.1× the initial processing throughput.

The distinction between counters is important. The processed-FPS figure was measured up to the OCR queue. The 25 FPS output counter doesn't establish that OCR, safety checks, encoding, and network delivery all finished within 40 ms. Throughput and end-to-end latency are different measurements.

I also tested this architecture with four simultaneous camera streams on the same RTX 5070 Ti. I'm not publishing per-stream throughput or latency figures for that configuration here, so the 24.64 FPS result should be understood as the single-stream measurement.

How to Troubleshoot Low FPS in a TensorRT Video Pipeline

If I encountered another RTSP application that wasn't keeping up with the camera, I'd check these boundaries before changing the model:

Decoder output: Is each decoded frame already GPU-accessible, or is a CPU image being uploaded for inference?
Preprocessing: Are resize, color conversion, letterboxing, and normalization creating unnecessary host buffers or synchronization points?
Inference buffers: Are input and output tensors already in device memory? Is execution being synchronized more often than necessary?
Postprocessing and tracking: Does the CPU need the full frame, or only boxes, keypoints, scores, and IDs?
Queues and counters: Where exactly is FPS measured? Does OCR or another downstream queue grow during a sustained run?

I'd also record stage timings and queue depth instead of relying on one FPS counter. A pipeline can appear fast at the inference stage while its end-to-end latency continues to grow.

For API details, NVIDIA documents PyNvVideoCodec decoding and interoperability and TensorRT asynchronous Python inference. These are references for implementing similar techniques, not code taken from the customer's deployment.

What I'd Do Differently Next Time

I'd diagram the entire frame path before spending time tuning inference: every buffer allocation, every CPU-to-GPU or GPU-to-CPU transfer, and every synchronization point.

In this project, that was where the meaningful improvement came from. A fast TensorRT engine didn't help much while the rest of the pipeline kept moving full-size frames around.

I shared more context and the original benchmark in my LinkedIn post about this RTSP/TensorRT optimization. If you've run into a similar bottleneck, I'd be interested to hear whether it was decoding, preprocessing, memory movement, or something else.

Implementation note: I configured and tested this pipeline on a customer's server. The performance figures come from that work. AI assistance was used to draft and edit the English text.

PHP2Shell on Ubuntu: How to Verify and Install the PHP Security Patch

Igor — Thu, 29 Oct 2026 12:44:30 +0000

On October 21, 2026, the PHP security team released emergency fixes for two critical vulnerabilities that could allow unauthenticated remote code execution (RCE).

The issues, commonly discussed as PHP2Shell, are tracked as:

CVE-2026-109618 — Remote code execution through out-of-memory corruption.
CVE-2026-109619 — Remote code execution through stale internal request state.

If you run PHP on an Ubuntu VPS, updating is important. But there's a detail that can easily cause confusion: an Ubuntu server can have the security fixes installed while php -v still reports an older upstream version.

For example, Ubuntu 24.04 can report PHP 8.3.6 even after installing the relevant security patches.

Here's how to check the actual package revision, identify which PHP runtime serves your website, apply the update, and verify the result.

This guide uses Ubuntu 24.04 LTS with PHP 8.3-FPM as its main example.

What exactly is PHP2Shell?

These vulnerabilities affect the PHP interpreter itself, not just applications built with PHP.

CVE-2026-109618: Out-of-memory corruption

PHP can encounter memory allocation failures while handling HTTP requests.

In affected versions, an out-of-memory condition can interrupt internal request initialization. During cleanup, PHP may subsequently treat partially initialized data as valid.

Under exploitable conditions, this can lead to memory corruption and remote code execution.

CVE-2026-109619: Stale global state

PHP workers can process multiple requests during their lifetime.

This issue involves internal request-owned state remaining accessible after its underlying memory has been freed.

A later request handled by the same worker may access stale state before normal initialization resets it.

That creates another potential remote code execution path.

Which environments are affected?

The official PHP security advisory identifies web-facing PHP installations, including:

PHP-FPM with Nginx
Apache with mod_php
PHP-CGI
FrankenPHP
LiteSpeed

The PHP team considers Apache with mod_php particularly high risk because a demonstrated attack can be triggered before application code executes.

Updating WordPress, Laravel, Drupal, or another PHP application does not fix these vulnerabilities in the underlying interpreter.

Which PHP versions contain the fixes?

On October 21, PHP published the following upstream security releases:

PHP branch	First fixed upstream version
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35

PHP 8.1 and older releases no longer receive regular upstream security updates, although some Linux distributions and long-term-support vendors maintain patched packages.

Here's the catch for Ubuntu administrators: upstream PHP version numbers and Ubuntu package revisions are not the same thing.

Why Ubuntu 24.04 may still show PHP 8.3.6

Canonical frequently backports security fixes into distribution packages instead of replacing the entire PHP version with the latest upstream release.

For Ubuntu 24.04 LTS, the first fixed PHP 8.3 package revision is:

8.3.6-0ubuntu0.24.04.13

Notice that the upstream part remains 8.3.6.

If you only run:

php -v

you might still see PHP 8.3.6 and conclude that your server is vulnerable.

That conclusion may be incorrect.

Canonical confirms the following fixed package revisions in Ubuntu Security Notice USN-8948-1:

Ubuntu release	PHP branch	First fixed package revision
22.04 LTS	8.1	`8.1.2-1ubuntu2.28`
24.04 LTS	8.3	`8.3.6-0ubuntu0.24.04.13`
26.04 LTS	8.5	`8.5.4-0ubuntu1.5`
26.10	8.5	`8.5.9-0ubuntu2.1`

These versions apply to the corresponding official Ubuntu packages.

If PHP was installed from a third-party PPA, a hosting control panel, or a custom source build, check that vendor's security advisory instead.

Step 1: Identify the Ubuntu release

Connect to your server through SSH.

Run:

cat /etc/os-release

Look for the VERSION_ID value.

For example:

VERSION_ID="24.04"

This tells you which Ubuntu security notice and package revisions apply to your system.

Now check the default PHP interpreter:

php -v

Keep in mind that this checks the command-line PHP binary, which may differ from the PHP installation serving your website.

Step 2: Identify the web-facing PHP runtime

A server can have several PHP versions installed simultaneously.

List installed PHP packages with their complete revisions:

dpkg-query -W \
  -f='${binary:Package} ${Version}\n' \
  'php8.*' 'libapache2-mod-php*' 2>/dev/null

Check the installed PHP-FPM services:

systemctl list-unit-files 'php*-fpm.service'

If your website uses Nginx, inspect the configured FastCGI targets:

sudo nginx -T 2>/dev/null | grep fastcgi_pass

This helps identify the PHP-FPM socket or upstream handling requests.

For Apache installations, inspect the loaded PHP-related modules:

sudo apachectl -M 2>/dev/null | grep -E 'php|proxy_fcgi'

Only run the web-server checks that apply to your environment.

For Ubuntu 24.04 with PHP 8.3-FPM, examine the package information:

apt-cache policy php8.3-fpm

The important fields are:

Installed: the package currently installed.
Candidate: the package available for installation.
Version table: where those packages come from.

Don't classify a server as patched solely because a newer package is available. Confirm the version that is actually installed and running.

Step 3: Install the Ubuntu security update

Before changing production packages, ensure that your application files, databases, and configuration are backed up.

For an installation using official Ubuntu repositories, refresh package indexes:

sudo apt update

Review available updates:

apt list --upgradable

During an appropriate maintenance window, apply the updates:

sudo apt upgrade

Read the proposed changes before confirming.

For packages maintained by Ubuntu, Canonical states that a standard system update generally installs the necessary corrections.

If your server uses third-party PHP packages, check their maintainer's instructions instead.

Verify the installed PHP package revision

On Ubuntu 24.04:

dpkg-query -W \
  -f='${Package} ${Version}\n' \
  php8.3-fpm

Compare the resulting revision with the version in USN-8948-1.

For example, an official Ubuntu package at revision:

8.3.6-0ubuntu0.24.04.13

contains the October 21 fixes.

A later package revision from the same maintained Ubuntu repository should also be checked against Canonical's advisories.

Remember: the package name and revision are only part of the answer. You also need to establish which PHP runtime is handling HTTP requests.

Step 4: Restart PHP-FPM or Apache

Updated PHP packages must be loaded into the processes serving requests.

For PHP 8.3-FPM, start by checking its configuration:

sudo php-fpm8.3 -t

If the configuration is valid, restart the service:

sudo systemctl restart php8.3-fpm

Check its status:

sudo systemctl status php8.3-fpm --no-pager

If the restart fails, inspect recent logs:

sudo journalctl -u php8.3-fpm -n 30 --no-pager

For Apache with mod_php, validate its configuration and restart Apache instead:

sudo apachectl configtest
sudo systemctl restart apache2

Avoid restarting unrelated services on a production system.

Check that the application is responding

You can perform a basic HTTPS check:

curl -fsS -o /dev/null \
  -w '%{http_code}\n' \
  https://example.com/

Replace example.com with your application domain.

A successful response confirms basic availability. It does not prove that the PHP vulnerabilities have been fixed.

That requires checking the installed vendor-fixed package and the runtime serving your application.

An additional PHP advisory from October 23

Two days after the PHP2Shell security release, the PHP team published an informational advisory about session upload progress.

It concerns a separate potential remote code execution scenario associated with CVE-2026-115560.

The issue requires an unusual combination of application behavior:

session.serialize_handler is configured as php_binary or php_serialize.
Application code changes the handler to php using ini_set().
The application calls session_start().
Session upload progress is enabled.

Applications that never change the serialization handler at runtime are not exposed through this specific scenario.

As of October 29, PHP recommends temporarily setting:

session.upload_progress.enabled = 0

For Ubuntu 24.04 with PHP 8.3-FPM, the main configuration file is typically:

/etc/php/8.3/fpm/php.ini

Edit the configuration if the recommendation is appropriate for your application:

sudoedit /etc/php/8.3/fpm/php.ini

After making the change, check for conflicting PHP-FPM pool or server configuration overrides.

Then validate and restart PHP-FPM:

sudo php-fpm8.3 -t
sudo systemctl restart php8.3-fpm

The setting must be applied before request parsing. Don't rely on changing it through application-level ini_set() or .user.ini.

Disabling session upload progress may affect applications that depend on this feature, so assess its impact before changing production settings.

This measure does not replace the PHP2Shell security updates.

The PHP team has also published other temporary mitigations for specific attack paths. Those measures reduce exposure but do not provide complete protection. Installing the security fixes remains the recommended solution.

What if PHP runs inside Docker?

If you deploy PHP applications in containers, updating Ubuntu on the host does not automatically update PHP inside those containers.

First list running containers:

docker ps

Identify the container serving your application.

Then check the installed PHP interpreter:

docker exec CONTAINER_NAME php -v

Replace CONTAINER_NAME with the actual container name.

For Docker Compose deployments:

docker compose images

Inspect the PHP image and check whether its upstream maintainer has released a patched version.

Depending on your deployment, you may need to pull an updated image or rebuild a custom image using a patched base.

For services that use published images, a typical deployment sequence is:

docker compose pull
docker compose up -d

For custom-built images, rebuilding and redeploying may also be required.

After deployment, verify the PHP installation inside the replacement container.

The same rule applies here: a PHP version banner alone might not reveal whether a distribution-based image contains backported security fixes.

When rebuilding on a new VPS makes sense

For a supported Ubuntu system, applying the available security updates is usually the most practical option.

However, moving to a fresh server may be worth considering when the existing environment is no longer maintainable.

Examples include an unsupported operating system, an abandoned PHP repository, incompatible legacy dependencies, or a server whose integrity can no longer be trusted.

If you need a new environment, Cherry Servers offers virtual servers with Ubuntu installation options, including Ubuntu 24.04 LTS.

A migration should begin with a clean, updated operating system, followed by a maintained PHP runtime and properly configured web server.

Before switching production traffic, restore the application from verified backups and test its functionality.

Rebuilding does not automatically resolve PHP security issues. New servers require regular patching, access controls, monitoring, and maintenance just like existing ones.

Affiliate disclosure: The Cherry Servers link above is an affiliate link. I may earn a commission if you purchase through it, at no additional cost to you.

How to confirm that PHP2Shell has been patched

A reliable verification should answer four questions:

Which PHP runtime serves incoming requests? The CLI interpreter may not be the same one your website uses.
Where did the PHP package come from? Official Ubuntu repositories and third-party sources can use different security patch schedules.
Does the installed package contain the vendor's fix? Compare its complete package revision with the corresponding security advisory.
Are the patched workers running? Restart or replace the affected processes, then verify application availability.

If these checks are complete, you have a stronger basis for assessing remediation than simply reading the output of php -v.

For Ubuntu 24.04, the key detail is that a properly updated PHP 8.3.6 distribution package can contain the October 21 security fixes.

The package revision matters more than the upstream version banner.