Is there an encryption scheme that is url-safe AND compact? I want to be able to encrypt some data like JohnSmith@domain.com|1234|A in a form that I can send to a user as a clickable link like:
https://example.com/click/this/NiUGgvamNOVmI1SzlTN0ZIRlQ0WklCazI3LzRxY09RVFRjOTByZ1o1OFJyT0lUeWd3PQ2....

Then the user clicks the link and when I receive the token, I can decrypt it and operate on the data.
I'm using the RijndaelManaged cipher, with a password and salt, and then Base64 encoding and then UrlToken encoding it, to avoid characters that would cause trouble in a url.
This all works fine, but it creates really long tokens, about 4 times the length of the original data, which makes sense, as it's smearing the information across all 256 possible bytes and then reducing to only 64 possible bytes for output.
What I am wondering is if there's a way to encrypt the data, possibly not as securely, but enough for limited application, that would not be 4 times longer than the input string. Could there be an algorithm that encrypts text AS text and without requiring vastly more size?
TL;DR You should use format-preserving encryption which is designed to solve your problem.
There are various solutions some of which are easier than others to implement. I'll estimate their sizes based on your example token and url.
Some less than perfect solutions
As suggested in the comments, a bitwise stream cipher (such as ChaCha) or block cipher in streaming mode (such as AES-CTR) followed by base 64 encoding and url tokenising will only make your string about 42% longer plus any IV overhead. You may or may not want to worry about the ability of the user to modify the data. A user who can identify their token data could then forge tokens of the same or shorter length.
Estimated token length with 128-bit IV: 61 characters.
Estimated url length: 92 characters.
By adding a MAC you can defend against token manipulation but add another 21-22 characters to both lengths. Modern authenticated encryption methods may integrate authentication codes automatically.
You can shave off some characters with shorter IVs and MACs, but I wouldn't recommend going below 64-bits. These would save you 10-11 characters.
Estimated token length with 64-bit IV: 50 characters (61 with 64-bit MAC).
Estimated url length: 81 characters (92 with 64-bit MAC).
If we assume that your tokens use a character set of size 65 {A-Za-z0-9@|.} You could index the set and use a mod 65 stream cipher which would preserve the character set. Again IVs and MACs would be advisable, but could be expressed in the character set. There aren't any off the shelf mod 65 stream ciphers, but one could be constructed based on established stream cipher designs.
Estimated token length: 40 characters (52 with short MAC)
Estimated url length: 71 characters (73 with short MAC)
My laptop browser has a 65 character address bar and so I like urls with fewer than 64 characters to inhibit malicious url suffixes such as @http://evil.com/malware.exe. None of these solutions manage to achieve this for your example.
The designed and standardised solution
You can create url-friendly tokens and then use format-preserving encryption for 0 overhead. NIST have a standard for FPE and googling for &quot;FF3-1 open source&quot; should find an implementation in your language of choice.
Estimated token length: 27 characters
Estimated url length: 58 characters
58 character urls are still longer than the address bar on my phone browser, but this is still pretty good.