Most e-signature workflows, including Microsoft's own eSignature for Word, do not sign the .docx at all. They render your Word file to PDF, collect signatures on the PDF, and give you a signed PDF plus an audit trail. Before picking a tool, decide which of two things you actually need.
An electronic signature collected through a signing workflow is what most offer letters, onboarding packets, and sales agreements use. The output is a signed PDF. A certificate-based digital signature embedded in the .docx itself is a different requirement: it proves the file has not changed since signing, but every signer needs a signing certificate.
Option 1: Word's built-in signature line
Word desktop can add a signature line (Insert, then Add a Signature Line). The signer right-clicks it and chooses Sign, which adds a visible signature and a digital signature at the same time. Per Microsoft's documentation, creating a digital signature requires a signing certificate issued by a certificate authority, and a signed document becomes read-only. This works for internal sign-offs where everyone already has a certificate. It is awkward for customers or new hires who do not.
Option 2: Microsoft 365 eSignature from Word
If your documents already live in SharePoint, Word can send signature requests directly: Insert, eSignature fields, add recipients, then Create request. Recipients sign an automatically generated PDF copy, and the signed PDF is saved next to the original Word file. The prerequisites are specific: a subscription version of Word desktop, a .docx stored in an eSignature-enabled SharePoint site, an unencrypted file, and an admin who has turned the feature on. It is a good fit when the people sending documents already work in Word and SharePoint.
Option 3: Convert to PDF yourself, then use any e-signature tool
If you are automating this, you can convert the .docx on your own server and send the PDF through whichever e-signature provider you already use. LibreOffice does the conversion from the command line:
soffice --headless --convert-to pdf --outdir out offer-letter.docx
# writes out/offer-letter.pdfTwo trade-offs come with this route. First, you own the conversion: LibreOffice is not Word, so check the output visually, especially if the document uses fonts that are not installed on the conversion server. Second, signature fields are usually placed by page and coordinates, and those coordinates break whenever someone edits the Word file and the text reflows. Placing fields by anchor text, or by placeholder tags typed into the document, holds up better than hardcoded positions.
Which one to pick
Need the .docx itself signed with certificates: use Word's signature line. Everyone works in Microsoft 365 and the volume is manual: use eSignature from Word. Sending documents from your own product or backend: convert to PDF and use an e-signature API, keeping the .docx as your editable source and the signed PDF as the record. In every case, finalize the content before you send it, because an edit after signing means collecting signatures again.
If you want to skip the conversion step, look for an e-signature API that accepts .docx uploads directly. Anvil's Etch e-sign API is one option: it converts an uploaded .docx to PDF on upload, and text tags typed into the Word file, such as {{signature:::signer1}}, become signature fields assigned to the signer with the matching id, so there are no coordinates to maintain.
Back to All Questions