Introduction

You can often open the device's messaging app from a web page with an sms: link, and many mobile clients support a prefilled message body through a body parameter. The catch is compatibility: this works fairly well on many Android devices, but it is not a fully reliable cross-platform web standard, and Apple does not officially document SMS body prefilling through the basic sms: URL scheme.

The Basic Link Format

The simplest version uses the sms: scheme plus a phone number:

<a href="sms:+15551234567">Text us</a>

On supported mobile devices, tapping that link opens the messaging app with the recipient number filled in.

To attempt a prefilled body, you typically add a query parameter:

<a href="sms:+15551234567?body=Hello%20from%20our%20site">
  Text us
</a>

The body text must be URL-encoded. Spaces become %20, line breaks become %0A, and other punctuation should also be encoded when necessary.

Generate the Link Safely with JavaScript

If the message comes from user or application data, build the URL with encodeURIComponent rather than hand-encoding characters.

1<a id="sms-link" href="#">Send order update</a>
2
3<script>
4  const phoneNumber = "+15551234567";
5  const message = "Order 4821 is ready for pickup at 5:30 PM.";
6
7  const url = `sms:${phoneNumber}?body=${encodeURIComponent(message)}`;
8  document.getElementById("sms-link").href = url;
9</script>

This avoids broken links when the body contains spaces, punctuation, or line breaks.

If you do not want to hard-code the number, you can omit it:

<a href="sms:?body=I%20have%20a%20question%20about%20my%20account">
  Send a message
</a>

Support for that format still depends on the platform and the installed messaging app.

The Cross-Platform Reality

This is the part many examples skip: there is no single web format that behaves identically on every phone.

On Android, sms:number?body=... commonly works with the default messaging app and many third-party clients.

On Apple devices, the official sms: URL documentation historically focuses on opening the Messages app with a recipient and does not formally specify a body parameter for the basic URL scheme. In practice, some web examples use body-prefill patterns that work on certain versions or clients, but you should treat that as best-effort behavior, not a guarantee.

Because of that, if the prefilled text is business-critical, test on the exact browser and device combinations your users rely on.

A Practical Fallback Strategy

If reliable prefilled text is optional, the link can degrade gracefully. The worst case is usually that the messaging app opens without the body text, and the user types the message manually.

For example, this is often good enough for support links:

<a href="sms:+15551234567?body=I%20need%20help%20with%20my%20order">
  Contact support by text
</a>

But if the message must contain structured data such as an order number, booking code, or one-time keyword, consider alternatives:

• use a native mobile app instead of a plain web link
• use a web form that submits directly to your backend
• use a share sheet integration in a hybrid or native app

Those approaches give you much better control than an sms: link.

Keep the Message Short and Intentional

Even where body prefilling works, treat it as a convenience, not a transport layer. SMS clients may split long messages, rewrite formatting, or show the user an editable draft before sending.

Good prefilled SMS content is:

• short
• immediately understandable
• editable by the user
• safe if sent as written

For example:

<a href="sms:+15551234567?body=BOOKING%201042%20-%20Please%20confirm%20arrival%20time">
  Confirm by SMS
</a>

That is far more robust than trying to pack a large amount of structured data into the draft message.

Common Pitfalls

The most common mistake is forgetting URL encoding. A message with spaces, ampersands, or question marks can break the link if you concatenate it directly.

Another issue is assuming the link behaves the same on iPhone and Android. It does not. Android support is generally better for body parameters, while Apple support is less formally defined and should be tested rather than assumed.

Desktop behavior is also inconsistent. On many laptops and desktops, sms: links do nothing useful unless the operating system has a compatible messaging app associated with the scheme.

Finally, do not build a critical workflow that depends on automatic sending. An sms: link opens a compose experience. The user still decides whether to send the message.

Summary

• Use an sms: link to open the messaging app from HTML.
• Prefilling the body with ?body= often works on Android but is not universally reliable.
• Always URL-encode the message text, ideally with encodeURIComponent.
• Treat prefilled SMS bodies as a convenience feature, not a guaranteed workflow.
• Test on your actual target devices before depending on the behavior.