I’m the maker of PreviewShip. This article was drafted with AI assistance, and it explains a practical PDF-sharing workflow and its limits.

A PDF attachment is a copy. Once it reaches five people, those five copies can outlive your next revision. A link gives you another option: send people a project URL that points to the document you published.

That does not mean the document must become an HTML page. It can remain a PDF, opened or downloaded by the recipient’s browser.

Start with the right kind of file

Suppose you have a non-confidential menu.pdf and want someone to open it from a browser. First, open it on your own device and check the version, page order, fonts, and embedded images. A renamed Word document is not a PDF merely because its filename ends in .pdf.

Before publishing, decide whether the content is suitable for a public URL. A guest PreviewShip link is public. If the file contains confidential material, do not use the guest flow. With Pro, choose Password access and set the password in the console deployment form before submitting the sensitive document; then test access in a separate browser. Password access is not the same as document-level rights management.

Create the link

For a document that can be public:

  1. Open the PDF upload flow and choose your .pdf file.
  2. Publish it and wait until the deployment is ready.
  3. Copy the project URL provided by the result.
  4. Open that URL in another browser or a private window. Check that it opens the intended document.
  5. Share the project URL with your readers.

The no-signup guest preview lasts 24 hours and accepts uploads up to 15 MiB. A guest project can be claimed to an account before expiry when account limits allow. Account plans have their own retention rules: a Free preview lasts three days, while an active Pro subscription supports continuous hosting.

The complete walkthrough is here: https://previewship.com/guides/upload-pdf-online?utm_source=devto&utm_medium=article&utm_campaign=previewship_1028&utm_content=article_01_pdf

Why use the project URL?

Opening a PDF project can redirect the browser to a path for the actual PDF file. Keep the project URL that the publish result provides rather than copying the destination from the browser after the redirect.

If you save the project and later deploy a revised PDF to that same project, the project URL can continue to point to the current version. It is still subject to the project’s plan, retention, and access settings. A fixed URL is not a promise that a free preview stays online forever.

A simple handoff might say:

The current menu is available at the project link. Open it in a browser; depending on your settings, it may display in the browser or download as a PDF.

That wording sets a reasonable expectation for mobile browsers and in-app webviews, which do not all display documents in the same way.

If the result is not what you expected

The upload is rejected: confirm that the file is a valid PDF, opens locally, and is within your applicable upload limit. Try a single direct PDF upload before diagnosing a ZIP with multiple competing files.

It downloads rather than displays: try a current standalone browser. PDF viewer behavior depends on the browser and its settings; the hosted file remains a PDF.

The recipient sees an expired link: check the project and plan in your account. Claiming an expired project does not automatically republish the document. Republish to the saved project if needed and check its current status.

You need annotations or signatures: use a document tool designed for those jobs. A PreviewShip PDF link hosts and shares the original document; it does not convert it to an HTML page or provide PDF editing, annotation, or e-signature features.

For a document intended to be shared publicly, the most useful habit is simple: keep the project link, check it in a second browser, and verify the retention period before sending it.