Get and convert PDF coordinates using JavaScript

When working with locations in WebViewer, it's important to understand which coordinate space they use. For example, when you set the (x, y) value of an annotation through the WebViewer API, the location is relative to the unzoomed page in viewer page coordinates, not PDF page coordinates.

In a PDF document, the location (0, 0) is at the bottom-left corner of the page. The x-axis extends horizontally to the right, and the y-axis extends vertically upward.

Here are some APIs to get a page's width and height.

A page may have a rotation or translation associated with it; in that case, (0, 0) may no longer correspond to the bottom-left corner of the page relative to the viewer.

For example, here is the same page as above but rotated 90 degrees clockwise. Notice how the coordinates have all stayed the same relative to each other, but (0, 0) is now in the top-left corner relative to the viewport.

Here is the getPageRotation API to get a page's rotation.

Generally, when you use WebViewer, you won't deal with PDF coordinates directly.

When reading or writing annotation locations in WebViewer, these values are in viewer coordinates. The (0, 0) point is located at the top left of the page. The x-axis extends horizontally to the right, and the y-axis extends vertically downward.

Viewer page coordinates are tied to the underlying page, not to how the page appears on screen. When you rotate a page, the same coordinates point to a different visual location in the viewport. To position annotations based on how they appear to the user, see Viewport-relative annotation positioning.

WebViewer uses a transformation matrix for each page to convert between PDF and viewer coordinates. The matrix accounts for flipped y values and possible translation or scaling.

Since XOD files are considered 96 DPI and PDF files 72 DPI, the scaling factor for XOD files is 96/72, or 4/3. For PDF files, there is no scaling applied, just the flipped y values.

Annotation locations inside XFDF are in PDF coordinates. When WebViewer imports an XFDF, it automatically transforms the locations into viewer coordinates using the matrix. When exporting XFDF, WebViewer reverses the process and converts back to PDF coordinates.

If you ever need to convert between PDF and viewer coordinates yourself, you can use the getPDFCoordinates function to get PDF coordinates or the getXODCoordinates (for XOD files) or getViewerCoordinates (for PDF or Office files) functions.

For example:

These coordinates are relative to the browser window, with (0, 0) in the top-left corner. The x-axis extends to the right, and the y-axis extends downwards as you scroll through the document content.

Note that the viewer's scroll position does not affect these coordinates. For example, if the user has scrolled to page 10, the window coordinates of the first page remain the same.

In the following image, you can see an example of the document scrolling downward, but the window coordinates for the pages stay the same.

WebViewer provides functions on the current display mode to convert between window and page coordinates. The pageToWindow and windowToPage functions. For example:

Mouse locations are relative to the viewport, so to convert to window coordinates you only need the viewer's scrollLeft and scrollTop values. If you're inside of a tool (for example, your own custom tool), you can use this.getMouseLocation(e) to get window coordinates from a mouse event.

Or manually using the scroll values from the viewer element:

This is what happens internally in the default tools, and as we saw above, you can transform window coordinates to page coordinates with a function call.

What if you want to double-click the page and add a DOM element there? You probably want the element to scroll with the page and be repositionable after the zoom changes. The easiest way to do this is to position it absolutely inside the pageContainer element.

You'll get the event object from the mouse double-click event, transform it into window coordinates, and convert those into page coordinates. DocumentViewer triggers a dblClick event so we can use that to get double clicks inside the viewing area.

You also need to figure out what page you double-clicked on, and you can use the getSelectedPages function to do this:

Once you have the page, you can get the page coordinates from the window coordinates:

Then you can create your custom element and add it to the page container element. Note that you need to scale the position and size by the zoom level.

You'll notice that if you change the zoom or make the page rerender, the elements will disappear. This is because when a page rerenders, it resizes and re-adds itself to the DOM.

To handle this, you can keep track of your custom elements and add them to the updated pageContainer on the pageComplete event. The full code looks like this:

Annotations normally store their location in page coordinates. This helps because the annotation stays tied to the underlying document page, but page rotation can make programmatic positioning less intuitive.

For example, consider a rectangle annotation placed near the top-left corner of a page. If you copy it to a page rotated by 90 degrees, copying the stored page coordinates directly can place the rectangle in a different visual corner or change its displayed orientation.

Viewport-relative positioning solves this by describing an annotation as it appears to the user in the current viewport. The viewport-relative values account for the page's effective rotation, including document page rotation and viewer rotation.

Use getViewportProperties to read the position, dimensions, and rotation of a rectangular annotation in viewport-relative coordinates.

The returned object contains:

These values describe where the annotation appears on the displayed page. This makes them useful when an application needs to align annotations with UI elements, templates, or coordinates received from another viewport-based workflow.

Use setViewportProperties to position and rotate a rectangular annotation using viewport-relative values.

WebViewer converts the values back to the annotation's stored page coordinates automatically. The x, y, width, and height properties are required. The rotation property is optional and defaults to 0.

setViewportProperties keeps the annotation within the viewport page bounds before converting it to page coordinates. If the requested geometry extends beyond the page, WebViewer adjusts the position and dimensions to fit.

Path-based annotations, such as lines and freehand annotations, can use viewport-relative path APIs. These APIs are useful when an annotation's visual shape must remain aligned with the displayed page after rotation.

Use getViewportPath and setViewportPath to read or write an entire path.

For workflows that edit a single path point, use getViewportPathPoint and setViewportPathPoint.

Use the viewportRelative paste option when copying annotations between pages that have different rotations. WebViewer transforms the copied annotation through viewport space, so its visual position and orientation are preserved on the target page.

When viewportRelative is true, WebViewer preserves the copied annotation's visual placement and orientation as closely as the target page allows. This is especially useful for stamps, free text, shapes, and freehand annotations.

If the source and target pages have different dimensions, WebViewer fits the result within the target page bounds.

The Settings Modal includes an Enable Viewport-Relative Annotation Positioning toggle under Advanced Settings > Annotations.

When enabled, standard keyboard paste uses viewport-relative positioning. Copying an annotation from one page and pasting it onto a page with a different rotation preserves the annotation's visual position and orientation.

When disabled, WebViewer uses the page-coordinate paste behavior. This maintains compatibility with workflows that expect annotation geometry to be copied directly in page coordinates.