How to Create a Link for a PDF Clients Can Open

You've just fixed two prices and a typo on a client's catering menu, and now you're staring at an email thread that already has three attachments named final, final v2, and final revised. Send a fourth and someone will approve the wrong one. That's exactly when you need to know how to create a link for a PDF instead of attaching the file again. Export one clean PDF, upload it to get a shareable browser link, check who can open it, and test that link in a private window before you send it. One address travels in the email, and the client always lands on the version you meant them to see.

Create a Browser Link for the PDF

Say a freelance designer is handing off that revised catering menu. The client doesn't need another attachment to download, lose, or confuse with yesterday's copy. They need one address they can tap in an email or chat and read straight away. Here's the sequence I'd run before anything leaves your outbox.

The five moves

1. Export a single PDF. Save the menu as one file with selectable text, not a flattened image of a page, and give it a filename a human recognizes, such as spring-menu.pdf. A clear name helps the client spot it later and helps you confirm you uploaded the right file.
2. Upload it for a browser link. Use the PDF to Link tool and add the file there.
3. Name the link, then add controls only if they're on your account. A password, expiry date, or view limit is useful for a price list or a dated quote. Don't promise a control in your email until you've seen the setting saved on that link.
4. Copy the HTTPS viewer URL. That's the public address clients receive, not a local file path from your computer.
5. Open it in a private browser window and turn every page. If page three is blank, cropped, or still shows last season's soup, you want to catch it now, not in the client's reply.

Our workflow follows four steps: upload a file, customize the link with a name and, on a paid plan, a password, expiry date, or view limit, share the link, and track visits and downloads. That order matters because the access choice belongs before the send, not after someone forwards the address. Recipients open the result in a normal browser and don't create an account or install an app, which removes the two most common reasons a client says they couldn't view a handoff.

Keep the address you sent as the address of record. A correction should land behind the same share, not behind a second URL that half the thread never sees.

Why one address beats another attachment

Attachments fork. One person saves the file to their desktop, another forwards the earlier copy, and a third prints from their phone before your correction arrives. A single viewer link keeps the conversation pointed at one destination you control. Creators run into the same forked-version problem with portfolios and one-sheets, which is why a tidy electronic press kit works on the same principle, one current destination instead of scattered files.

Don't shorten or retype the URL by hand to make it look neater in the email, either. Paste the exact address you tested, put it behind descriptive words if your email tool allows it, and leave it alone. A link that differs by one character from the one you checked is an untested link. By the end of this step you should have the URL copied, the private window pass done, and no attachment sitting in the draft.

Fix the PDF Before You Publish the URL

A polished viewer link still fails a client who can't select, search, or hear the menu read aloud. The link is only the delivery step. The document itself has to be readable, and that work happens before upload, in whatever tool produced the PDF.

A short production checklist

• Keep real text. Export from the source document instead of photographing or scanning a printed page, so words stay selectable and searchable.
• Set a meaningful document title. The title is often the first thing assistive technology announces, and it's more useful than an exporter's default filename.
• Use a logical heading order. Section headings for starters, mains, and desserts should follow the order a reader meets them, not the order the layout tool placed the text boxes.
• Add alt text for informative images. A photo that shows a plated dish or a venue layout needs a short description. A purely decorative flourish doesn't.
• Check color contrast. Pale gold type on cream may look elegant in print and disappear on a phone in daylight.
• Make tables read in sequence. Prices, allergens, and portion sizes should make sense when read row by row, not as columns shuffled together.
• Name links inside the PDF. Use words like Full spring menu rather than Click here, so the destination is clear out of context.

The World Wide Web Consortium's PDF techniques identify Tagged PDF as the most reliable way to generate an accessible PDF, because tags carry structural information and reading order to screen readers and help content reflow for different screen sizes, and they also specify that link text should describe its target clearly and accurately. After the URL is live, open the linked file and move through it with the keyboard, and with a screen reader when your audience needs one. A practical companion check is reviewing how the document reads on a small phone screen, since cramped pages test reading order faster than a desktop monitor does.

State the limit plainly to yourself before you send. The browser address makes delivery easier, and it cannot add missing headings, fix a scrambled reading order, repair untagged tables, or describe an image that has no alternative text. If a PDF can't be made readable, offer an HTML page with the same facts so nobody is locked out of the information.

Choose Access and Test the Link Before Sending

Decide who can open the PDF before the address leaves your hands, because the access rule is part of the handoff. A public menu, program, or brochure can stay open to anyone who has the link. A client proposal or price list is different, and it deserves a deliberate choice rather than a default you never looked at.

Shared PDFs on LinkShip may be accessible to anyone with the link unless password protected, so treat an unprotected address as something that can be forwarded. If your plan offers password protection, apply it to the viewer for sensitive work, and remember it's a gate on the link, not protection baked into the file itself. For a quote that expires or a dated event handout, set an expiry date and then read the saved date back to confirm it matches the one you picked. Save each control on this link only, and don't stack settings your account doesn't show you.

The broader principle is well established. Adobe's guidance on sharing PDFs notes that recipients can open a shared PDF in a browser without signing in, and it identifies three access choices, anyone on the internet with the link, anyone in the organization with the link, or invited people only, which shows why the permission setting, not the copied address alone, decides who gets in. If you're weighing how far to restrict a particular document, the secure document sharing advice from Bizbe is a useful prompt for thinking about download controls before distribution, and a closer look at file access rules helps you match the setting to the audience.

Run the send gate

Test in a private browser window, where you're not signed in as the owner. Open the copied URL, confirm the PDF loads with no sign-in prompt you didn't intend, and turn the pages. Repeat it on a phone browser and check the text is readable without pinch zooming on every line. Look at the address bar and confirm it's showing the HTTPS viewer URL you copied. Where a password or expiry is set, try once without the password and once with it, so you know the gate blocks and admits the right way.

Pre-send checks for a PDF link. Run each check in a private browser window before the link leaves your hands.

Send gate: If the link only works while you're logged in, it isn't ready for the client.

Send the email, chat message, or handout only after every check you need passes. A failed row isn't a reason to attach the PDF as a backup. It's a reason to fix the setting, retest the same address, and then send once, cleanly. That discipline is what separates a link you hope works from a link you've watched work under the client's conditions.

Fix Stale Pages After a File Update

You've replaced the PDF behind the link, the client opens it, and they're still looking at last week's prices. Before you assume the update failed, reopen the same link in a fresh private window and check two things, the page count and the first page. Those two details usually tell you immediately whether you're seeing the new file or an old copy.

Check the browser before you blame the link

If the old version appears, reload the page in a way that bypasses the locally stored copy, then check again in a second browser. A different result in the second browser points at the first browser's cache, which keeps a stored copy of a page so repeat visits load faster. Stale pages after an update usually come from that cache, not from the link itself, and they clear once the browser fetches the current file.

Public, version-stable PDFs handle caching well, since a stored copy can be checked against the current file and refreshed only when it changes. Password-protected or expiring PDFs are different. They shouldn't sit in a shared or long-lived cache where the wrong person or an out-of-date copy can surface after access was meant to end, so don't rely on default caching behavior for those.

Hold the send if the new pages don't appear

If the old version persists after a clean reload and a second-browser check, don't send a second link. Note the filename and the time you made the change, hold the message, and retest until the new pages show. Only then tell the client the document is current, and tell them in the same thread where the original link lives, so they reopen the address they already have.

Resist attaching a copy of the PDF as a fallback while you wait. A saved attachment is the version clients are most likely to keep, forward, and reference weeks later, long after you've corrected the linked file. The whole point of the stable address is that there's one current document to argue with. Protect that by being patient for one retest cycle instead of creating a rival copy you can't update.

Add a QR Code and Send the Link Once

Add a QR code only when the same PDF has to be reached from paper, a table tent, a printed program, or a handout someone is holding. Email doesn't need one. Create the normal HTTPS viewer URL first, test it the way you'd test any client link, and then encode that address in the code. You're encoding the link, not the PDF itself, so the destination stays a page you can maintain after printing.

Keep the encoded address short

Payload length is the quiet reliability factor. A controlled QR usability study reported 100% successful outcomes for 100 to 400-byte payloads, versus 18.2% for 1,700 to 2,000-byte payloads, and the longer group also produced 59.1% wrong scans and 22.7% aborted scans. Long tracking strings and storage paths make a dense code that's harder for a phone camera to read at an angle or in dim light. Use the short viewer address, skip extra parameters you don't need, and let the code stay open and scannable.

• Match error correction to the setting. Level M, about 15% recovery, suits a plain code; level H, about 30%, suits a code with a logo or one likely to get scuffed or partly covered. LinkShip's QR designer picks for you: M for a plain code, H once you add a logo.
• Preserve the quiet zone. The blank border around the code is how scanners find its edge. Cropping it for a tighter design breaks scans.
• Keep strong contrast and adequate module size. Dark modules on a light background, with modules of at least 3 to 3.5 pixels, decode more reliably.
• Print the fallback URL beside the code. A short visible address gives people with an older phone, a cracked lens, or no camera permission a way in.
• Test at final print size. Scan the actual printed piece on more than one phone, in ordinary light, at the distance a guest will stand.

Print pieces that earn repeat scans reward the same care, whether the destination is a menu PDF or you print QR codes for Google reviews on a counter card. Point the code at a stable viewer or redirect URL rather than a changeable storage path, so a later file update doesn't strand every printed copy. Paid LinkShip users on Tiny, Solo, Pro, and Pro Max can replace a supported individual PDF while keeping the same public URL, which is exactly the behavior printed material needs. If you want the fuller print workflow, the walkthrough for a PDF QR code covers placement and sizing in more depth.

A printed code outlives your email. Send it only to an address you're prepared to keep current.

Make the send a single action

For the digital handoff, paste the tested viewer URL into the client email, proposal, or chat, and don't attach a second copy of the PDF. Two copies invite the client to read the wrong one and make your correction invisible. Before the message goes out, upload the current client PDF with the PDF to Link tool if you haven't already, run the private window check once more, confirm the first page and page count, and then send. One upload, one address, one message. That's a handoff the client can open on the first tap, and one you can stand behind when they reply.

---

Turn your next client PDF into one browser link you can test, protect, and update without resending attachments. Visit LinkShip to upload the file, copy its viewer URL, and send it once with confidence.