My "Send to Claude" URLs Were Too Long: Japanese Swells to About 9 Characters per Character, So I Moved the Full Text to Notion

Good morning, まさきん here.

The notifications that land on my phone have a “Send to Claude” button. Tap it, and a Claude chat opens with that content already filled in. The problem: long Japanese text would not fit in the URL. Today I want to write up the workaround I landed on, which is moving the full text over to Notion.

*This information is current as of publication. Please check the official websites for the latest terms.

Notifications ended with just reading them

At home, I get recurring household reports and failure alerts via Telegram. The results of my automations keep arriving on my phone one after another. I have also written before about having AI check my card spending every night.

But notifications tended to end the moment I read them. Even when I thought “what should I do about this?”, opening Claude and pasting things in was just a bit of a hassle. So I decided to put an entry point for asking Claude right on the notification itself.

How the button works

Each notification has a button labeled ”🤖 Send to Claude”. Behind it is a URL of the form claude.ai/new?q=<request text>. Tap it, and a Claude chat opens with the request text already entered.

The button is a Telegram InlineKeyboardButton. The official Bot API says the url field accepts “HTTP or tg:// URLs”. On the other hand, callback_data, which is sent back to the bot when the button is pressed, is limited to 1-64 bytes. Since all I need here is to open a URL, the url field alone is enough.

Japanese swells to 9 characters per character

This is where I hit the first wall. Put Japanese into a URL, and the character count shoots up.

Only a fixed set of characters can be used in a URL. Everything else gets replaced using something called percent-encoding. RFC 3986 specifies that one byte is written as three characters: ”%” followed by two hexadecimal digits.

Japanese characters are usually 3 bytes in UTF-8. The table in RFC 3629 also shows this range as a 3-byte sequence. Each of the 3 bytes becomes 3 characters, so one character turns into about 9. For example, the hiragana character for “a” becomes %E3%81%82.

Once I understood the mechanism, it all made sense. By this math, 200 Japanese characters make a URL of nearly 2,000 characters.

My original preamble alone went over 2,000

At first, I prepended a fairly long preamble to each request. Something like “This is an automated notification from my home.” But that preamble by itself went over 2,000 characters after encoding.

So I cut the preamble way down and got it through. Still, with a long body, I would run into the same problem again. That is when I felt I needed somewhere else to put the text.

There is no universal limit on URL length

So how many characters can a URL hold? From what I found, there does not seem to be a single universal limit.

RFC 9110, the HTTP specification, recommends supporting URIs of at least 8,000 octets. But that is a recommended minimum. It does not set a maximum. If a URI is too long, a server may respond with “414 URI Too Long”.

How much length is handled differs by browser, app, and every service in between. So in my setup I went with roughly 2,000 as a guideline. That number is no guarantee it will work everywhere.

”+” and ”%” got garbled

Another thing that quietly tripped me up was symbols. In the text passed to ?q=, ”+” and ”%” got garbled. Even with correct encoding, the displayed text came out broken.

In the URL world, there is a convention of reading ”+” as a space. The WHATWG URL Standard also has a step that replaces ”+” with a space when parsing form-style data. I will not claim here exactly where the garbling happened.

I kept the fix simple. Before sending, I replace ”+” and ”%” with the full-width ”＋” and ”％”. Since the request text is meant for a human to read, full-width characters rarely cause trouble, I think.

Long text now goes to Notion

Now for the main workaround. I stopped putting long text into the URL.

Instead, I write the full text to a Notion database I call “Claude Handoff”. The button URL carries only that page ID and the opening lines. Claude then goes and reads the Notion page using that ID.

I actually sent both short and long versions and confirmed they work.

What the Notion API can do

With Notion’s official API, you can create pages under a database. You specify an existing page or data source as the parent.

On the reading side, you can pull a page’s information by specifying its page ID. However, the page body goes through a separate endpoint. The official docs say it is read with the “Retrieve block children” API.

Limits are another thing to watch. According to the official request limits, the content of a single rich text object is capped at 2,000 characters. Rather than cramming long text into a single block, it may be safer to split it up.

For Claude to read it, you need to have the Notion connector connected. Connectors are how Claude accesses data in external services. The official help center says they inherit the permissions of the person who connected them.

The flow, step by step

Laid out as a flow, my setup looks like this.

1. The notification script prepares the notification text and the request text.
2. It replaces ”+” and ”%” in the request text with full-width characters.
3. It checks whether the encoded length is within the guideline.
4. If it is short, it puts the text straight into ?q= and builds the button.
5. If it is long, it writes the full text to the Notion handoff database.
6. It puts only the page ID and the opening lines into ?q= and builds the button.
7. It sends the notification and button to Telegram.

As pseudocode, it looks roughly like this.

text = request text with "+" and "%" replaced by full-width
if encoded length <= guideline:
    q = text
else:
    ID = save full text to Notion handoff DB
    q = "Read Notion page " + ID + ". Opening: " + start of text
button URL = "https://claude.ai/new?q=" + encode(q)

I split button building into its own script

At first, I was assembling the URL inside the notification-sending script. But as the replacements and length checks piled up, it got hard to follow.

So I split the button-URL logic into its own small script. The notification side just receives the finished URL. Even as I add more kinds of notifications, I can reuse the same piece.

I have also written about what goes on behind my automations in my post on the Cron limit on the Cloudflare Workers free plan. Keeping things small and separate makes later fixes much easier.

How the Mac desktop app differs

I also tried the Claude desktop app on my Mac. With claude://new?q=, the app just launched. The text did not come through.

With claude://claude.ai/new?q=, on the other hand, the text came through. The official help center lists this format too. It also says the q text is truncated at about 14,000 characters, and that all values must be URL-encoded.

Note that, officially, the url field on a Telegram button takes HTTP or tg:// URLs. Please treat that as a separate matter from putting claude:// directly into a button.

If you run your household errands from a single phone, it is worth reviewing your phone bill too. The more notifications and AI conversations you have, the more your phone becomes your window onto daily life.

Common mistakes and pitfalls

I think this setup suits people who tend to read a notification and just move on. It may also suit people who want to consult AI about the results of their automations. That said, there were a few places where it is easy to stumble.

• Making the preamble so long that the body no longer fits
• Counting characters and overlooking the length after encoding
• ”+” or ”%” getting garbled and changing the meaning of the request
• Mixing tokens or personal IDs into the button URL
• Handoff pages piling up faster than you can clean them up

The token issue in particular deserves care. URLs are easily seen by others through history or sharing. Putting only the handoff page ID in the URL feels like the safe choice, doesn’t it?

I am still working on cleaning up the handoff pages myself. Automatic archiving after 7 days is not implemented yet. I wrote about how rules alone do not get followed in my post counting 164 tasks. Getting the system to tidy up after itself is still on my to-do list.

What to check before you start

• Whether your notification service supports URL buttons
• Whether you have a way to count the encoded length of the request text
• Whether you have decided how to handle the plus and percent symbols
• Whether you have set up a place to offload long text (such as Notion)
• Whether you have connected the Notion connector to Claude
• Whether you have kept tokens and personal IDs out of the URL
• Whether you have a rule for cleaning up handoff pages

FAQ

Q. Why do URLs get so long with Japanese?

Most Japanese characters take 3 bytes in UTF-8. In a URL, each byte is written as the three characters “%XX”. So each character swells to about 9 characters.

Q. How many characters can a URL hold?

There does not seem to be a single universal limit. The HTTP specification recommends supporting at least 8,000 octets. But the actual limit differs by browser and service. In my setup, I went with roughly 2,000 as a guideline.

Q. Is claude.ai/new?q= an official feature?

For the web version, I could not confirm it in the official documentation. It works right now, but it may change in the future. For the desktop app, claude://claude.ai/new?q= is listed in the official help center.

Q. Why do ”+” and ”%” get garbled?

In URLs, there is a convention of reading ”+” as a space. That said, I have not pinned down exactly where the garbling happened in my setup. As a fix, I replace them with full-width characters before sending.

Q. Can a Telegram button carry long data?

callback_data is limited to 1-64 bytes. It is not suited to carrying long text. That is why I went with keeping the full text in Notion.

Q. How does Claude read the full text stored in Notion?

You connect the Notion connector to Claude. Using the page ID in the URL as a pointer, Claude goes and reads the page. I confirmed it actually works with both short and long text.

Q. Don’t the handoff pages pile up?

They do. I have not yet built the automatic archiving after 7 days. It is one of my open items right now.

Official sources I referred to

• Telegram Bot API (InlineKeyboardButton, sendMessage)
• RFC 3986 (URI syntax, percent-encoding)
• RFC 3629 (UTF-8)
• RFC 9110 (HTTP semantics, URI length, 414)
• WHATWG URL Standard (form-style parsing)
• Open Claude Desktop with a link (Claude Help Center)
• Open the Claude mobile app with a link (Claude Help Center)
• Use connectors to extend Claude’s capabilities (Claude Help Center)
• Notion connector (Claude)
• Create a page (Notion API)
• Retrieve a page (Notion API)
• Retrieve block children (Notion API)
• Request limits (Notion API)

Wrapping up

Adding a “Send to Claude” button to notifications dramatically shortens the distance to asking for help. But Japanese swells about ninefold inside a URL. I settled on sending short text as is and offloading long text to Notion.

The remaining homework is cleaning up the handoff pages. If you tend to read notifications and let them slide, why not try adding a single button?

This article contains affiliate advertising. If you sign up for a product or service through a link on this site, we may receive compensation from the partner company. The site operator is also an employee of Rakuten Group and may receive compensation through an employee referral program. The content and opinions here are based on the operator’s own experience and research regardless of any advertising relationship, but please read with the above in mind. See the Disclaimer & Affiliate Disclosure for details. Disclaimer & Affiliate Disclosure

This article includes machine-translated content. Please check the official Rakuten Mobile multilingual page for exact terms.

If you have concerns about Rakuten Mobile coverage or signal quality, you can consult through the official signal improvement request form .