All documentation

Attachments

Update attachments let you keep a supporting file beside an update or a client reply. Use them for material that helps the reader understand or review the update, such as a PDF proof or an image. The written update should still explain the result, request, or change. A file with no explanation makes the client guess why it was sent.

Add update attachments

You can attach one file when you post an update. The update form accepts PNG images, JPEG images, PDF documents, and plain text files encoded as UTF8. The file must be nonempty and no larger than 5 MiB.

To post an update with a file:

  1. Open the project from the project list.
  2. Write the update in the New update field.
  3. Select Attach a file, then choose one supported file.
  4. Check that the selected file name appears beside the control.
  5. Select Post update.

The update and its attachment are posted together. The client receives the update email, and the project page shows the attachment under the update. The email directs the client to the project page rather than placing the file inside the email message.

Choose the final file before you post. There is no control to replace an attachment, add another attachment to an existing update, edit an update, or delete an update. If you selected the wrong file, post a new update that clearly identifies the corrected file. If the mistake exposes information to someone who has the client link, create a New link immediately and then use the support link in the site footer for help.

Attach files to a client reply

A client can attach up to three files to one reply. Client replies accept PNG images, JPEG images, and PDF documents. Each file must be no larger than 5 MiB. Plain text files are accepted on owner updates, but they are not accepted on client replies.

To send reply attachments, the client opens the client link and finds the relevant update. They enter their name and reply, select Attach files, choose up to three supported files, and select Send reply. The reply and file links then appear beneath that update. You receive an email notification that points back to the reply in your owner view.

The reply needs both a name and written text. Attachments cannot be submitted as a file only reply. A name can contain up to 80 characters, and reply text can contain up to 5,000 characters.

Why a file can be rejected

The service checks more than the file name. An update attachment must have a supported extension and content that matches the expected file signature. A renamed executable does not become a PDF merely because its name ends in .pdf. Plain text must be valid UTF8 and must not contain null bytes.

Reply attachments receive an additional browser media type check. The extension and the media type reported by the upload must agree, and the file content must pass the same signature check used for update attachments. The service rejects unsupported extensions, mismatched media types, mismatched signatures, empty files, oversized files, and too many files.

If an upload fails, read the error shown beside the form. Correct the named problem and select the files again. Browsers do not restore file selections after a rejected form submission, so the form may keep your written text while requiring you to choose the file again.

Try these checks before contacting support:

  1. Confirm that an update has only one selected file, or that a reply has no more than three.
  2. Confirm that every file is within 5 MiB, not merely close to 5 MB under a decimal measurement.
  3. Open the file in its normal application to confirm that it is not damaged.
  4. Export the file again in a supported format instead of changing its extension.
  5. For a text attachment, save it as UTF8 plain text.

If a valid file is still rejected, use the Support link in the site footer.

How downloads and access work

Attachments do not have independent public URLs. A download request must include the current project token and must match an attachment recorded for that project. The browser downloads the content as a file rather than displaying it as a trusted image, document, or web page.

Anyone who has the current client link can read the project and download its attachments. Clients do not need an account. Treat the link as private access information, and send it only to people who should see the full project history.

Selecting New link creates a different project token. The old client page and the old attachment routes stop working. The files remain connected to the project and are available through the new link. Send the new link to every intended reader because their old bookmarks and old email links will no longer open the project.

The service does not scan downloads for malware. Format and signature checks reduce obvious mismatches, but they do not prove that a file is safe. Only upload files you trust, and tell clients to apply their normal security checks before opening a download. Do not use attachments for secrets or information that requires named user access, access logs, or separate permissions for each reader.

Choose update attachments that meet the file limits and help the client understand the written update. For help with project links and unsupported project changes, read Managing Projects. For what recipients receive after you post, read Email Delivery. The guide explains how to write the update that gives each attachment its context.