# How much does it costs to send SMS with Toky?

You can use Toky to send SMS in few clicks. Every text message has a price per SMS which you can find in our [coverage page](https://toky.co/en/coverage).

The price per SMS applies for texts **up to 140** characters in GSM-7 encoding or **65 if you use special characters like emojis.** If you send a longer text, it will be divided into blocks of 140 or 65 chars each, depending on the encoding, and every part will be charged as one message. The text blocks are reassembled as one message on the destination.

#### Why are there two different text limits? <a href="#why-are-there-two-different-text-limits" id="why-are-there-two-different-text-limits"></a>

The limit of 140 characters only applies to regular characters of the [GSM-7 encoding](https://en.wikipedia.org/wiki/GSM_03.38#GSM_7-bit_default_alphabet_and_extension_table_of_3GPP_TS_23.038_.2F_GSM_03.38) which require 1 byte for transference, if you use special characters like '{' and ']' the encoding could change to [UCS-2](https://en.wikipedia.org/wiki/Universal_Coded_Character_Set) encoding because these characters require 2 bytes, so the message limit changes to 65 characters.

For example:

* *"Hi, this is a test message"* has 26 characters and needs 26 bytes for transference.
* *"Hi, this is a test {message}"* has 28 characters and needs 30 bytes for transference. This is because the "{" and "}" symbols requires 2 bytes instead of one.

You can check the length of your messages in [this tool](http://chadselph.github.io/smssplit/) before sending bulk messages using our API or our [Bulk SMS add-on](https://tokyapp.zendesk.com/hc/en-us/articles/360020813298).

You must get an [SMS enabled phone number](https://tokyapp.zendesk.com/hc/en-us/articles/360020676937) in order to send and even receive text messages.

If you check your SMS and see that you've only used 140 characters but it seems that the message has more than 2 segments please consider the following.

<figure><img src="https://766977813-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FMgClsjsTSlUrSU2WhwDe%2Fuploads%2Fgit-blob-de92f2884dd80f4d48dddac2382f24639fa7558e%2Ftwo_segments.width-800.png?alt=media" alt=""><figcaption></figcaption></figure>

The answer to this lies in the encoding. This message has [UCS2](https://en.wikipedia.org/wiki/Universal_Coded_Character_Set) listed as the encoding instead of GSM. To accommodate a message like the example Toky and the carriers need to use a different character set..

When you send messages with non-GSM characters such as Emojis a different type of encoding known as [UCS2](https://en.wikipedia.org/wiki/Universal_Coded_Character_Set) is used.

[UCS2](https://en.wikipedia.org/wiki/Universal_Coded_Character_Set) takes 16 bits to encode each character so going back to the above example we now have a limit of 70 characters (140 bytes \* 8 bits in a byte / 16 bits).

Besides emojis you should also be careful with accented characters. GSM 03.38 includes some accented characters such as ñ, à, and ö, but does not include others such as á, í, or ú.

#### What Exactly Does A Data Header Do? <a href="#what-exactly-does-a-data-header-do" id="what-exactly-does-a-data-header-do"></a>

Still, it does not make sense for you that the message has 4 segments, and it should be three.

The answer to this is the concatenation. When you send multisegment messages we use [User Data Headers](https://en.wikipedia.org/wiki/User_Data_Header) to tell the destination how to reassemble it.

This takes up 6 bytes per message leaving only 67 characters for [UCS2](https://en.wikipedia.org/wiki/Universal_Coded_Character_Set) encoded messages or 153 for GSM encoded messages.

Maybe it turns out the fire emojis aren’t worth it after all. However, when you trim the same message down and resend it, it still doesn’t seem to work out quite right:

<figure><img src="https://766977813-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FMgClsjsTSlUrSU2WhwDe%2Fuploads%2Fgit-blob-7df8b6abc7046893ae3597f78f639658ac3d3b04%2Fone_segment_reduced.width-800.png?alt=media" alt=""><figcaption></figcaption></figure>

This message contains two of the **“gotchas”** that commonly cause encoding issues: smart quotes and non-GSM spaces. Take a look at this message that appears almost identical:

<figure><img src="https://766977813-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FMgClsjsTSlUrSU2WhwDe%2Fuploads%2Fgit-blob-5d1aa6aecea57e12695d47fc8e638a24e59aa9fe%2FImage02.width-800.png?alt=media" alt=""><figcaption></figcaption></figure>

Non-GSM spaces are usually a result of copying and pasting. Be extra careful with those as they’re often converted to conventional spaces for display. This includes de Toky SMS box. This means sms bodies that contain non-GSM spaces will be formatted as regular U+0020 spaces for display.

#### Is this a limitation imposed by Toky? <a href="#is-this-a-limitation-imposed-by-toky" id="is-this-a-limitation-imposed-by-toky"></a>

No, this is how SMS work across the industry.