How Do Electronic Signatures Work? The Full Mechanism

TL;DR: An electronic signature works in nine stages: you prepare a document and place fields on it, the platform generates a unique private signing link for each recipient, the recipient opens it, proves who they are (email possession, often plus a one-time code), consents to sign electronically, performs a signing action (drawing, typing, uploading an image, or clicking), and the platform then seals everything into a tamper-evident PDF. That sealed file carries a SHA-256 fingerprint of the signed content and a certificate of completion listing timestamp, IP address, device, and the full event history. The signature itself is not the interesting part. The audit trail is. That record is what makes the signature defensible under the ESIGN Act and UETA, and it is the reason an e-signature produces far stronger evidence than a scanned wet signature emailed as a PDF.

Ask how do electronic signatures work and most explanations stop at "you click a link and sign on your phone." That is accurate and completely useless if you want to understand whether the thing will hold up when a client claims they never agreed.

This guide takes the machine apart. What software actually does between the moment you press Send and the moment a sealed PDF lands in two inboxes. What gets recorded, at what precision, and why. What a cryptographic hash is and why a 64-character string proves a document was not edited. Which identity checks prove what, and which prove almost nothing. And where the legal requirements of ESIGN and UETA map onto specific technical steps, rather than floating above them as vague reassurance.

If you want the definitional layer first, read what is an electronic signature. If you want the legal layer, read are electronic signatures legally valid. This article is the mechanical layer: how electronic signature works as a system, from the file on your desktop to the sealed record in your archive. It assumes you have a reason to care about the details.

The end-to-end flow in one pass

Before the detail, here is the whole sequence. Electronic signing of documents follows the same shape on every reputable platform, including [okdoc](/):

• 1. Prepare. You upload a PDF or create the document in the platform, then place fields on it: signature, date, name, initials, text, checkbox. Each field is assigned to a specific recipient role.
• 2. Send. The platform creates a recipient record for each signer, generates a long random access token for each one, builds a unique URL from that token, and delivers it by email, WhatsApp, or SMS.
• 3. Open. The recipient clicks. The platform resolves the token to the recipient record, logs an "opened" event with a timestamp, and renders the document in the browser. No account, no download, no software install.
• 4. Verify identity. At minimum, the recipient proved possession of the inbox or phone number the link was sent to. If the sender required it, a one-time passcode adds a second, time-boxed proof.
• 5. Consent. The recipient affirmatively agrees to use electronic records and signatures, and cannot proceed until they do.
• 6. Sign. They perform a deliberate signing action: drawing, typing, uploading an image, or clicking. Consent and intent are two separate things and the law treats them separately.
• 7. Capture. At the instant of signing, the platform records the signature artifact plus a bundle of context: exact timestamp, IP address, user agent, which fields were filled with what, and the consent event.
• 8. Seal. Once every required signer is done, the platform flattens field values into the PDF, appends a certificate of completion, and computes a cryptographic fingerprint of the canonical signed content.
• 9. Distribute and retain. The sealed file is stored and a copy goes to every party.

Nine stages. The rest of this article is what happens inside each one.

Stage 1: Preparing the document

Where the document comes from

There are two starting points, and they behave differently downstream.

An uploaded PDF. You take a file you already have: a lease, an NDA, a purchase order. The platform stores it and treats every page as a fixed canvas. Fields are positioned on top of it by coordinate.

A document created inside the platform. The content lives as structured data or rich text, not as a fixed page image, so it can be re-rendered, translated, or laid out responsively for a phone. In okdoc this is the "page" document type, and it is what makes AI-generated proposals and quotes possible: the assistant writes the body, and the body is real content rather than a picture of content.

The distinction matters for sealing, which I will come back to. A PDF is sealed as its original pages plus your field values burned in. A generated document is sealed by rendering its stored content to PDF at completion time.

Fields are coordinates, not pictures

When you drag a signature box onto page 3 of a contract, you are not drawing on the file. You are creating a database row that says, roughly: field type `signature`, page 3, x 0.62, y 0.31, width 0.22, height 0.06, assigned to recipient 2.

Nothing is written into the PDF at this point. The original file is untouched. That is deliberate: the source document must stay pristine so that at the end you can show exactly what was presented and exactly what was added.

Field types you will typically place:

• Signature — where the signing artifact lands.
• Initials — for per-page acknowledgment on longer agreements.
• Full name and email — usually pre-filled from the recipient record so they cannot silently be changed.
• Date signed — normally auto-populated by the server, not typed by the signer, because a signer-typed date is worth nothing evidentially.
• Text — free entry for things like a company number or an address.
• Checkbox — for discrete acknowledgments ("I have read Schedule B").

AI field auto-mapping, which okdoc ships on every plan including FREE, is a convenience layer over this step: the model reads the uploaded PDF, finds the signature lines and the blanks, and proposes the coordinates for you. It is a time saver. It changes nothing about how the field data is stored or sealed.

Roles decide who fills what

Each field is bound to a recipient role, not to a person's name. This is what makes templates reusable: "Signer 1" and "Signer 2" are slots, and you drop actual people into them at send time. Roles also carry different powers:

• Signer — must complete their assigned fields and sign. Their action is required for the document to be complete.
• Approver — must approve before the flow proceeds, but does not sign.
• Viewer / CC — receives a copy, cannot alter anything.

Get roles wrong and you get the single most common e-signature support ticket: a signer who cannot find the signature box, because it was assigned to somebody else.

Stage 2: Sending, and what a signing link really is

The link is a credential

This is the part almost nobody explains, and it is the most important security fact in the entire system.

When you send a document, the platform creates one recipient row per person and attaches a long, random, unguessable access token to each one. The signing URL is that token: something of the shape `okdocai.com/sign/<token>`. When the recipient clicks, the server looks up the token, finds exactly one recipient row, and grants access to exactly that recipient's view of exactly that document.

There is no password. There is no account. The URL is the credential. Possession of the link is what authorizes access.

Three consequences follow, and all three are practical:

• 1. Never forward a signing link. Forwarding it hands over the ability to sign as that recipient. If a colleague should sign instead, the sender must reassign the recipient, which issues a new token and invalidates the assumption that the original person acted.
• 2. Every recipient gets their own link. If a platform sends one shared link to five people, the audit trail cannot distinguish between them. That is a design flaw, not a feature.
• 3. Tokens should be long and random. A token with enough entropy is not brute-forceable in any practical sense. Sensible platforms also rate-limit the signing endpoints so automated guessing gets shut down rather than merely being slow.

Delivery channels

Email is the default because an email address is also an identity anchor. WhatsApp and SMS are faster in practice, particularly for real estate agents and anyone closing on the phone, where a link that arrives during the conversation converts and a link that arrives tomorrow does not.

The channel affects both delivery rate and what identity is proved. A link delivered to an email address proves the signer had access to that inbox. A link delivered to a phone number proves they had access to that device. Neither proves who the human is, which is the honest limit of possession-based verification. More on this in Stage 4.

What happens the instant you hit Send

Sending logs a `sent` event with a timestamp, and from that moment the document is a live object rather than a file you released into the void.

This is where okdoc's [Track](/) stage sits, and it is the beat most e-signature tools simply do not have. From the moment you send, you can see whether the document was opened, how many times, how long the recipient stayed, how much time they spent on each page, how far they scrolled, where they clicked, and whether the deal is running hot, viewed, stalled, or abandoned. A WhatsApp alert fires the moment the client opens it, so you can call while the document is still on their screen.

Two things worth stating plainly, because they are unusual. First, all of that is on the FREE plan at ₪0 — tracking is not gated behind any tier. Second, it is a genuinely different question from "did they sign." A signer who opened your proposal four times and spent nine minutes on the pricing page has not signed, but they have told you exactly what to say when you call. Signing is one beat of five: Create, Send, Track, Sign, Close.

Stage 3: The recipient opens the document

The recipient clicks. The server resolves the token, checks the document is still open for signing (not expired, not voided, not already complete), and logs an `opened` event.

At this moment the platform typically records:

• Timestamp, at second precision or finer, stored in UTC.
• IP address, as observed by the server.
• User agent, the browser's self-description of its software and device.
• Which recipient the token belongs to.

The document then renders in the browser. No download, no Adobe Acrobat, no account creation. This matters more than it sounds: every extra step between the link and the signature is a place where deals die, and the whole reason e-signing a document beats print-sign-scan is that the friction is gone.

A note on IP addresses and user agents: they are context, not identity. An IP address locates a network connection, roughly and imperfectly, and can be shared by an entire office or masked by a VPN. A user agent is self-reported and trivially spoofable by anyone who wants to. Their evidentiary value is corroborative. If a signer claims they were never involved, and the record shows the document was opened three times over two days from the same IP block as their earlier correspondence, on the same iPhone user agent, that is a difficult story to maintain. No single field carries the argument. The pattern does.

Stage 4: Identity verification, and what each method actually proves

This is where honest platforms and marketing copy diverge. Here is what each method genuinely establishes.

Email or phone possession

What it is: the link went to `dana@acme.com`, and someone opened it from that link.

What it proves: whoever signed had access to the message sent to that address. Nothing more.

Why it is usually enough: for ordinary commercial agreements, this is the same standard of proof most business communication runs on. If you would accept a contract term agreed over that email address, you can accept a signature initiated through it. Under ESIGN and UETA the question is whether the signature can be attributed to the person, and attribution is proved by "the efficacy of any security procedure applied" together with the surrounding context, not by a single magic factor.

Where it is weak: shared inboxes (`office@`, `info@`), forwarded links, and any situation where a colleague routinely handles someone else's mail.

One-time passcode (OTP)

What it is: before the signature is accepted, the platform emails or texts a short numeric code, and the signer must enter it back into the signing page.

What it proves: the signer had live, real-time access to that inbox or phone at the moment of signing. That is meaningfully stronger than possession of a link that may have been sitting in a thread for a week.

How it is implemented properly. Details matter here, and they are checkable:

• The code is short-lived. In okdoc it expires after 10 minutes.
• The code is never stored in plain text. It is hashed, and the stored hash is compared against the hash of what the signer typed. A read of the database does not reveal a usable code.
• Both sending and verifying are rate-limited, per token and per IP, so a six-digit code cannot be brute-forced.
• The verification is recorded as its own event, so the audit trail shows a second factor was satisfied.

OTP is a per-document toggle in okdoc, available on every plan. Turn it on for anything where the money or the risk justifies one extra step: employment paperwork, client engagement letters, high-value contracts. Leave it off for a ₪900 quote where an extra step costs you conversions.

Higher-assurance methods

Above OTP sit government-ID checks, knowledge-based authentication, and qualified certificates issued by accredited trust service providers. These exist for regulated instruments and for jurisdictions where a specific statutory signature level is required. They cost more, they add friction, and for the overwhelming majority of business agreements they are not what anyone uses. If your document type requires one, that requirement will come from a statute or a regulator, not from a vendor.

Stage 5: Consent and intent, the two separate legal switches

People collapse these into one idea. The law does not.

Consent to do business electronically

Before an electronic record can substitute for a written one, the signer has to agree to transact electronically. In a properly built signing flow this is an explicit, affirmative act: a checkbox immediately above the signing button, reading something like I agree to use electronic records and signatures, with a link to a full e-sign disclosure that explains what that means, how to get a paper copy, and how to withdraw consent.

Two design rules make this hold up. The checkbox must be unticked by default, because a pre-ticked box is not affirmative consent. And the signing button must be disabled until it is ticked, so consent provably precedes signature rather than sitting decoratively beside it.

For consumer transactions where a law requires a record to be provided in writing, ESIGN adds specific consumer-consent requirements in 15 U.S.C. §7001(c): clear disclosure of the right to a paper copy, of the hardware and software needed, and consent given in a way that reasonably demonstrates the consumer can actually access the electronic form. Business-to-business agreements are generally not subject to that consumer subsection, but the discipline is cheap and worth keeping.

Intent to sign

Consent says I am willing to do this electronically. Intent says I mean this mark to be my signature on this document.

UETA defines an electronic signature as an electronic sound, symbol, or process attached to or logically associated with a record and executed or adopted by a person with the intent to sign the record. That last clause carries the whole weight. A name typed at the bottom of an email is not automatically a signature. The same name typed into a field labeled "Signature," on a page where the button says "Sign and complete," after a consent checkbox, is a very different artifact, because the interface makes intent unambiguous.

This is why signing UX is a legal feature, not a cosmetic one. Every label, every button verb, every confirmation step exists to make it hard for a signer to later argue they did not know they were signing.

Stage 6: The signature itself, and what each type means evidentially

There are four common ways to produce the mark. They differ far less than people assume, and the difference that matters is not visual.

Drawn

The signer draws with a finger, a stylus, or a mouse on a canvas element. The browser captures the stroke path and produces an image, which is stored with the signature record.

Evidentially: it looks the most like a wet signature and is the most reassuring to non-lawyers. Handwriting-comparison value is low, because a finger-drawn signature on glass does not reproduce the motor characteristics of pen on paper. Its real value is the same as every other type: it is a deliberate act, and it is bound to the audit trail.

Typed

The signer types their name and the platform renders it in a signature-style font.

Evidentially: identical in standing to drawn. Both ESIGN and UETA are explicitly technology-neutral, and neither privileges one visual form over another. Typed signatures are often the most honest option, because they do not pretend to be handwriting analysis material. They also work best on desktop, where finger-drawing is genuinely awkward.

Uploaded image

The signer uploads a scan or photo of their handwritten signature.

Evidentially: the weakest of the four in isolation, precisely because it is the most re-usable. An image file can be copied from any previously signed document and pasted anywhere. Its authority comes entirely from the surrounding record: who was authenticated, when the upload happened, from which IP. Standing alone as a JPEG in a PDF, it proves close to nothing. Which, as it happens, is the entire problem with scanned wet signatures.

Click-to-sign

The signer clicks a button that says "Sign," and the platform records the click as the signature, usually rendering the signer's name as the visual mark.

Evidentially: perfectly valid. UETA's "sound, symbol, or process" language was written broadly on purpose, and a logged, authenticated, timestamped click is a process. It is the lowest-friction option and therefore the highest-converting, which matters when the alternative is a signer abandoning a proposal on a phone.

So which should you use?

For most business documents the honest answer is that the type is a UX decision, not a legal one. The evidential weight sits almost entirely in the audit trail, not in the shape of the mark. Pick the one your signers complete fastest. If a specific counterparty, insurer, or lender has a stated preference, follow it, because arguing about it costs more than complying.

Stage 7: What is captured at the moment of signing

The signature image or typed string is the smallest part of what gets stored. Here is the actual bundle.

The timestamp. Recorded server-side in UTC, at the moment the server accepts the signature. Server-side matters: a client-side timestamp is whatever the signer's device clock says, and device clocks can be wrong or deliberately changed.

The IP address. As observed by the server on the request that submitted the signature. Corroborative, as discussed.

The user agent. The full browser string, recorded internally. Note a privacy nuance in how good platforms handle this: okdoc records the raw user agent in the audit data but prints only a coarse device class on the distributed certificate of completion. The full string can identify a device with uncomfortable precision, and a certificate is a document that gets forwarded to accountants, lenders, and opposing counsel. The evidence is retained; the over-sharing is not.

The consent event. That the e-sign consent box was ticked, and when.

The identity verification result. Whether OTP was required, and whether it was satisfied.

Every field value. Each text box, checkbox, date and initial the signer filled, stored as data against its field. Not just a picture of the filled form: the actual values, individually.

The sequence of preceding events. Created, sent, opened (each time), reminder sent, and finally signed. Each with its own timestamp.

Individually these are unremarkable facts. Collectively they answer the questions a dispute actually turns on: who, when, from where, on what device, having agreed to what, having been shown which version, having filled in exactly which values.

Stage 8: Sealing, or how a 64-character string proves nothing changed

This is the part people find genuinely mysterious, and it does not need to be.

What a hash function is

A cryptographic hash function takes an input of any size and produces a fixed-length output. Feed it one word or a 400-page PDF and you get back the same size of result. Three properties make it useful:

• 1. Deterministic. The same input always produces the same output. Every time, on every machine, forever.
• 2. Avalanche effect. Change the input by the smallest possible amount, a single character, a single bit, and the output changes completely and unpredictably. Not slightly. Entirely.
• 3. One-way. You cannot work backwards from the output to reconstruct the input, and you cannot practically construct a second, different input that produces the same output.

The everyday analogy is a fingerprint. A fingerprint is small, it belongs to exactly one person, and you cannot rebuild the person from it.

What SHA-256 is

SHA-256 is a specific hash function from the SHA-2 family, standardized by the U.S. National Institute of Standards and Technology in FIPS 180-4. It produces a 256-bit output, which is written as 64 hexadecimal characters. It is the same function underpinning a great deal of modern internet security, including certificate chains and Bitcoin.

A SHA-256 digest looks like this:

`a3f1c9e0b7d4…` and so on to 64 characters.

The number of possible outputs is 2 to the power of 256. That number is large in a way that resists intuition, and the practical consequence is the one that matters: nobody can produce a different document that happens to yield the same fingerprint.

Why this proves a document was not altered

Here is the mechanism, end to end.

When every required signer has completed, the platform assembles a canonical representation of the signed content. In okdoc that payload includes the document id, the title, the signer's name and email, the exact signing time, the contract body (for generated documents), a hash of the signature artifact itself, and every field value, sorted into a stable order so the same content always serializes identically.

It runs SHA-256 over that payload. It gets 64 characters. It prints them on the certificate of completion under the label CONTENT FINGERPRINT (SHA-256), and stores them alongside the sealed file.

Now, later, someone hands you a PDF and claims it is the agreement. You re-derive the fingerprint from the stored record and compare.

• Identical strings → the content is bit-for-bit what was signed.
• Different strings → something changed. Maybe a number in a payment schedule. Maybe a date. The fingerprint does not tell you what changed, only that the file in front of you is not the file that was signed.

That asymmetry is the whole trick. Someone who edits a signed contract can make the edit invisible to the eye. They cannot make it invisible to the hash.

What "tamper-evident" actually means

It is worth being precise, because vendors are often not.

Tamper-proof would mean nobody can alter the file. That is not achievable. Anyone with a copy of a PDF can open it in an editor and change it. Physics and file systems do not care about your contract.

Tamper-evident means any alteration is detectable. The file can be changed; the change cannot be hidden. This is the achievable and honest claim, and it is the one that matters legally, because the question in a dispute is never "could this have been edited" but "can we demonstrate whether it was."

Where PKI digital signatures fit

A step beyond content hashing is a digital signature in the cryptographic sense: the sealed document is signed with a private key belonging to a certificate issued by a certificate authority, and any PDF reader can verify the corresponding public key. This is what produces the green validation banner in Adobe Acrobat.

Note the terminology trap, because it causes real confusion. "Electronic signature" is the legal category: any electronic mark made with intent to sign. "Digital signature" is a cryptographic technique used to protect and validate a document. They are different layers, and a document can have one, both, or the first without the second. Our page on digital signatures covers this distinction in more depth.

What the sealed file contains

The finished artifact is a single PDF containing:

• The original document pages, with every field value flattened into them so the visible file is the complete agreement.
• The signature marks rendered in position.
• An appended certificate of completion listing document title, document id, the SHA-256 content fingerprint, signer name and email, exact signing time, IP address, device class, issuing organization, and the full chronological audit trail.

One file. Self-contained. Readable by anyone with a PDF reader, requiring no account and no access to the platform that produced it. That last property is the one to check when evaluating any e-signature vendor: if your account disappeared tomorrow, would the signed document still stand on its own? It should.

Stage 9: Distribution and retention

On completion the sealed PDF is delivered to every party, and stored in the sender's account. Both matter for different reasons.

Delivery matters because ESIGN and UETA both require that a signed record be retainable and accurately reproducible by the parties entitled to it. A signature locked inside a vendor's portal that a counterparty cannot download is a compliance problem waiting to happen.

Storage matters because disputes surface late. Two years after signature, the argument is not usually about whether a signature happened. It is about which version was signed. A stored sealed file with a fingerprint answers that question in about thirty seconds.

Multi-signer mechanics: sequential vs parallel

When more than one person signs, ordering becomes a real design decision.

Sequential

Signers are ordered. The first receives their link on send. When they complete, the platform automatically issues the link to the second, and so on. Only one person can act at any moment.

Use it when order carries meaning. The employee signs, then the manager countersigns. The tenant signs, then the landlord. The contractor signs, then finance approves. Sequential order encodes a real-world approval chain, and the audit trail then proves the chain was followed in the right direction.

It is also the right choice when a later signer's decision depends on what an earlier one entered. Nobody should countersign a form whose numbers are still blank.

Parallel

Everyone is emailed at once and can sign in any order. The document completes when the last required signer finishes.

Use it when order is irrelevant and speed is everything. Three co-founders signing the same resolution. Four board members acknowledging a policy. Parallel is faster by exactly the amount of time your slowest signer would otherwise have spent as a bottleneck.

The cost is that you lose the ordering evidence, and you cannot make one signer's view depend on another's input.

How the mode changes what gets sent

The mechanical difference is in delivery. In parallel mode the platform emails every recipient at send time. In sequential mode it emails only the first, and each completion triggers the next invitation. Everything else — tokens, tracking, capture, sealing — is identical.

okdoc supports both, on every plan including FREE, along with roles for signer, approver, and viewer.

Why order can matter legally

Beyond workflow tidiness, ordering can be substantive. If your agreement says it takes effect on countersignature by the company, the audit trail showing the client signed at 14:02 and the company at 16:40 establishes the effective date. Parallel signing gives you the same two timestamps but does not evidence that one was a response to the other. When the sequence is part of the deal, encode the sequence.

The legal layer as a practical checklist

The U.S. framework is two statutes working together. The federal ESIGN Act (15 U.S.C. §7001 et seq., in force since 2000) and UETA, the Uniform Electronic Transactions Act drafted by the Uniform Law Commission in 1999 and adopted in some form by nearly every state. New York is the notable exception, using its own Electronic Signatures and Records Act instead. ESIGN largely defers to UETA where a state has adopted it.

Rather than restate the statutes, here is what they require translated into things you can actually check.

1. Consent to electronic records. Did the signer affirmatively agree to transact electronically, before signing, with access to a disclosure explaining the arrangement and how to get a paper copy? → An unticked-by-default checkbox that gates the sign button, plus a linked disclosure.

2. Intent to sign. Is it unambiguous that the signer meant the mark as their signature on this record? → Fields labeled "Signature," a button labeled "Sign," a confirmation step. Interface language is evidence.

3. Attribution. Can the signature be attributed to that specific person, by the security procedure applied and the surrounding circumstances? → Unique per-recipient token, delivery to a verified address, optionally OTP, IP and device recorded.

4. Association with the record. Is the signature logically bound to the specific document and version, not floating free? → Field coordinates tied to the document, the certificate embedded in the same file, the SHA-256 fingerprint covering both content and signature together.

5. Retention and accurate reproduction. Can each entitled party retain the record and reproduce it accurately later? → Sealed PDF distributed to all parties, downloadable, readable without the platform.

Hit all five and you have done what the statutes ask.

What ESIGN does not cover

This part is skipped in most vendor marketing, and skipping it is exactly why some people get burned.

ESIGN §7003 carves out categories where an electronic signature does not automatically get the same effect as a written one. They include:

• Wills, codicils, and testamentary trusts.
• Adoption, divorce, and other family law matters.
• Most of the Uniform Commercial Code, with specific exceptions.
• Court orders, notices, and official court documents.
• Notices of cancellation or termination of utility services.
• Notices of default, foreclosure, repossession, or eviction under a primary-residence rental agreement.
• Notices of cancellation of health or life insurance benefits.
• Product recall notices affecting health or safety.
• Documents required to accompany the transport of hazardous materials.

Several of those are counterintuitive. Eviction and utility-cancellation notices sit next to wills on the same list.

So the accurate statement, and the one worth repeating, is this: e-signature platforms are designed to support legally binding electronic signatures under ESIGN and UETA for ordinary business agreements. Anyone claiming their product is "legally binding in all 50 states" for everything is either not reading §7003 or hoping you will not. For the excluded categories, and for regulated instruments generally, check the specific requirement before you send. Our page on e-signature legality covers the international picture, including eIDAS in the EU and Israel's Electronic Signature Law.

What makes a signature challengeable in practice

Disputes are not abstract. They arrive as one of a small number of specific claims. Here is each one, and what defeats it.

"I never signed that." Defeated by the token trail: the link went only to their address, was opened from a consistent IP and device, an OTP delivered to their inbox was entered correctly, and the signature was submitted from the same session. Not one fact. A convergent set.

"That is not the document I signed." Defeated by the SHA-256 fingerprint. Re-derive and compare. Either the content matches what was sealed or it does not, and there is no room to argue about it.

"I did not know I was signing." Defeated by interface evidence: the consent checkbox, the field labeled Signature, the button labeled Sign, the confirmation. This is why sloppy signing UX is a genuine liability and why "we just had them reply YES to an email" is a bad idea.

"I never agreed to do this electronically." Defeated by the logged consent event with its timestamp, and by the disclosure that was linked at that moment. If your flow has no explicit consent step, you have no answer here.

"Someone else had access to my email." The hardest one, and the one possession-based verification cannot fully close. Mitigated by OTP, by device consistency, and by context (did they later act on the agreement, pay the deposit, take delivery, respond to it?). This is precisely the risk OTP exists to reduce, and precisely why you should switch it on when the amount at stake justifies one extra step.

"The terms were changed after I signed." Defeated by the fingerprint, again, plus the flattened field values on the sealed copy.

Notice what all six have in common. None of them is won by the signature image. Every one is won by the record around it.

E-signature vs a scanned wet signature emailed as a PDF

This comparison is worth making explicitly, because print-sign-scan still feels safer to a lot of people, and the feeling is exactly backwards.

What a scanned wet signature produces as evidence:

• An image of a signature on a page.
• A PDF whose creation metadata can be trivially altered.
• An email header showing a file was sent, from an address, at a time.
• No proof of what the signer was shown before signing.
• No proof of who operated the scanner.
• No proof the file was not edited afterwards.
• No consent record.
• No identity verification beyond the sending address.

What an e-signature produces as evidence:

• Every element listed in Stage 7, timestamped.
• A cryptographic fingerprint covering content plus signature.
• A logged consent event.
• Optional second-factor verification.
• A full chronology from creation to completion.
• A self-contained certificate anyone can read.

The signature image in the wet-signature case may be more visually convincing, and it may even be forensically comparable to other handwriting samples. But almost nothing else in that package can be verified, and the file itself is completely unprotected. An e-signed document is weaker in exactly one place, handwriting comparison, and stronger in every other place that a dispute actually touches. That is not a close call.

The same reasoning applies to the intermediate hack people use: pasting an image of your signature into a Word document. That is an uploaded-image signature with none of the audit trail, which is to say the weakest signature type stripped of the thing that gives signature types their weight.

Security: what is actually protecting the process

The mechanism is only as good as the plumbing under it.

Encryption in transit. All traffic runs over HTTPS with TLS, and okdoc sends HTTP Strict Transport Security so browsers will connect only over an encrypted channel. Documents and signatures do not travel in the clear.

The link as a credential. Covered in Stage 2, and worth repeating because it is the risk most people underestimate. Treat a signing link like a password. Do not forward it. Do not paste it into a group chat. Do not post it anywhere.

Rate limiting. Sensitive endpoints, including OTP send and OTP verify, are rate-limited per token and per IP address. This is what makes a short numeric code safe: guessing is not merely slow, it is cut off.

Hashed secrets. OTP codes are stored hashed, never in plain text. API keys are stored as hashes too, with the full key displayed exactly once at creation.

Tenant isolation. Each organization's data is isolated at the database level using PostgreSQL row-level security, so queries are scoped to the acting organization and one customer cannot read another's documents.

Encrypted payment credentials. When an organization connects a payment provider for Sign & Pay, the provider credentials are encrypted at rest with AES-256-GCM before storage.

Full detail, including infrastructure and responsible disclosure, is on the okdoc security page. One thing you will not find there, and should not find on any honest vendor page that does not hold them: claims of SOC 2, ISO 27001, or PCI certification. okdoc does not hold those. Stating what is true and verifiable beats implying what is not.

How to actually do it: a walkthrough

Concretely, start to finish, for a first document.

1. Create an account. Sign up with an email address. No credit card required. The FREE plan is ₪0 and includes 5 deals a month, where a "deal" means a document actually sent. Drafts never count against it, so you can experiment freely.

2. Get your document in. Either upload an existing PDF, or generate one with AI by describing what you need. AI generation is credit-metered rather than plan-gated, so it is available on FREE too.

3. Place the fields. Upload a PDF and let AI field auto-mapping propose the signature lines and blanks, then correct anything it got wrong. Adjust positions by dragging.

4. Add recipients and choose the mode. Enter each signer's name and email or phone, assign roles, and pick sequential or parallel. If order matters, sequential. If it does not, parallel.

5. Decide on identity verification. Turn OTP on if the value or risk justifies one extra step. Leave it off if friction will cost you the deal. This is a per-document decision, so make it per document.

6. Send. Choose email, WhatsApp, or both. The platform generates one unique link per recipient and delivers.

7. Watch. This is the step most people skip and should not. Open the tracking view and see when it was opened, how long they stayed, which page held them, how far they scrolled. Take the WhatsApp alert as a cue: a client with your proposal open right now is the best call you will make today. If a document goes quiet, that is data too, and it is what reminders are for.

8. Collect the sealed copy. When the last signer completes, the sealed PDF with its certificate of completion is generated and distributed. Download it and file it. That single file is your evidence package.

If your assistant is already where you work, you can drive the whole sequence from a chat window instead. See signing documents from ChatGPT and Claude.

Common mistakes worth avoiding

Sending one link to a shared address for multiple signers. The audit trail cannot then attribute anything to anyone. One recipient, one link, always.

Using a signer-typed date field. Auto-populate the date server-side. A date a signer types is a date a signer chose.

Skipping the consent step to reduce friction. It is one checkbox and it defeats an entire category of challenge. Removing it saves you nothing and costs you the answer to "I never agreed to sign electronically."

Treating OTP as all-or-nothing. It is per-document. High value, turn it on. Low value, leave it off. Blanket policies in either direction are wrong half the time.

Not downloading the sealed copy. Vendors change, accounts lapse, subscriptions get cancelled by someone in finance. The sealed PDF is self-contained by design. Keep it somewhere you control.

Assuming everything can be e-signed. Read §7003 once. It takes four minutes and covers a lifetime of edge cases.

What plan you need

Every mechanism described in this article — digital signature and sealed tamper-evident copy, multi-signer with roles, OTP verification, PDF upload with AI field mapping, WhatsApp and email delivery, and the whole Track layer — ships on FREE at ₪0, 5 deals a month. Prices below are in Israeli shekels.

CLOSE at ₪199/month raises the cap to 50 deals and adds automations with adaptive reminders and landing-style signing pages. AGENCY at ₪499/month goes to 200 deals with 10 seats, and adds the REST API, webhooks, and the MCP connector, which is the line that matters if you are an agency wiring signing into your own systems.

The full breakdown is on pricing, and if you are comparing against an incumbent, okdoc vs DocuSign does that directly.

Frequently asked questions

How does an electronic signature work, in one paragraph? You place signature fields on a document and send it. The platform generates a unique private link per recipient. The recipient opens it, proves identity through possession of their email or phone (optionally plus a one-time code), consents to sign electronically, and signs by drawing, typing, uploading an image, or clicking. The platform records the timestamp, IP address, device, consent, and every field value, then seals the finished document into a tamper-evident PDF carrying a SHA-256 content fingerprint and a certificate of completion.

How does e signature work if I have never used one before? From the signer's side it is three actions: click the link you were sent, tick the box agreeing to use electronic records, and sign by typing or drawing your name. There is nothing to install and nothing to download. Everything described in this article — token resolution, event logging, sealing, fingerprinting — happens on the platform's side without you doing anything.

How does e-sign work for the person sending the document? You upload or generate the document, place the fields, add recipients, choose sequential or parallel order, decide whether to require a one-time code, and send. After that your job is to watch: opens, dwell time, page-level attention, and the completion event. Electronic document signing is genuinely faster for the sender than for the signer, because template reuse and AI field mapping remove the preparation work that used to dominate the process.

What is actually recorded when I sign electronically? Timestamp in UTC, IP address, user agent and device class, the identity verification result, the consent event, every field value you entered, the signature artifact itself, and the full chronology of the document from creation through every open to completion.

Does the type of signature affect whether it is valid? Not materially. ESIGN and UETA are technology-neutral. Typed, drawn, uploaded, and click-to-sign all qualify as electronic signatures when made with intent to sign. The evidential weight lives in the audit trail, not in the visual form.

How does the SHA-256 fingerprint prove the document was not altered? SHA-256 turns any content into a fixed 64-character string, and changing even one character in the content produces a completely different string. Store the fingerprint at signing time, re-derive it later, compare. Match means unchanged. Mismatch means something was altered, though not which part.

Is "tamper-evident" the same as "tamper-proof"? No, and the difference is important. Nobody can stop you editing a PDF you hold. Tamper-evident means any edit is detectable. That is the achievable claim, and it is what matters in a dispute.

What is the difference between an electronic signature and a digital signature? Electronic signature is the legal category: any electronic mark made with intent to sign. Digital signature is a cryptographic technique using keys and certificates, often applied to seal and validate the file. They operate at different layers and are frequently combined. See our page on digital signatures.

Is e signing a document safer than emailing a scanned signature? Substantially, for evidence. A scanned signature emailed as a PDF gives you an image and an email header, with no consent record, no identity verification, no protection against later editing, and no proof of what was shown before signing. Electronically signed documents give you all of that.

Do I need an account to sign a document someone sent me? No. Signing is done through the link you received, in a browser, on any device. No account, no download, no app. Only the sender needs an account.

What does a one-time passcode actually prove? That the signer had live access to that specific inbox or phone number at the moment of signing. That is stronger than possession of a link that may have been sitting in a thread for days. In okdoc the code expires after 10 minutes, is stored hashed rather than in plain text, and both sending and verifying are rate-limited.

Can I send one document to several people to sign? Yes, in two modes. Sequential routes it to each signer in a defined order, releasing the next link on each completion. Parallel emails everyone at once and completes when the last one signs. Both are available on every plan, including FREE.

What happens if a signer forwards their signing link? Whoever holds the link can sign as that recipient, because the link is the credential. That is why you should never forward one. If the wrong person was addressed, the sender should reassign the recipient, which issues a fresh link.

Are electronically signed documents accepted everywhere? For ordinary business agreements in most jurisdictions, yes. But ESIGN §7003 excludes specific categories including wills, family-law matters, court documents, and certain notices such as utility cancellation and residential eviction. Check the requirement for your document type. E-signature legality has the international detail.

How long do e signed documents stay valid? The signature does not expire. What can degrade over time is your ability to prove things about it, which is why retention matters: keep the sealed PDF, because e-signed documents carry their own evidence inside the file and do not depend on your subscription still being active.

How do I know a signed document is genuine years later? Open the sealed PDF and read the certificate of completion: it lists the document id, the SHA-256 content fingerprint, the signer, the exact signing time, the IP address, the device class, and the full audit trail. It is self-contained, so it does not depend on still having access to any platform.

Can I electronically sign a PDF for free? Yes. You can sign a PDF free, and okdoc's FREE plan at ₪0 covers 5 sent deals a month including sealing, multi-signer, OTP, and full tracking. A deal counts only when a document is actually sent, so drafts are unlimited.

What is the difference between tracking and knowing whether someone signed? Signed is a binary at the end. Tracking is what happens in between: opens and how many, dwell time per open, time on each page, scroll depth, a click heatmap, deal heat, and a live WhatsApp alert when the client opens the document. It tells you which deals are alive and what the client is stuck on, days before the signature does. In okdoc it is free on every plan.

Bottom line

An electronic signature, how it works and what it is worth, comes down to one idea: it is not a picture of a name. It is a process that produces evidence.

Everything that makes it work sits in that process: a unique link that functions as a credential, an identity check calibrated to what is at stake, an explicit consent step, an unambiguous signing action, a captured bundle of context around the exact moment of signing, and a cryptographic fingerprint that makes any later alteration detectable. The visual mark is the least consequential part of the whole system.

Understand that and two practical decisions follow. First, judge any e-signature platform by the record it produces, not by how the signature looks. Second, notice that signing is only one beat of a longer sequence: create, send, track, sign, close. The signature is what ends the deal. Knowing what the client did with your document in the four days before is what gets you there.

Ready to see it end to end? Sign up free, send your first document, and watch the audit trail build itself. Or read how it works for contracts, quotes and proposals, and freelancers.