Help talk:URL

Encoding

As best I can see, only these characters require encoding:

sp	!	"	,	'	;	<	>	?	[	]
%20	%21	%22	%2c	%3a	%3b	%3c	%3e	%3f	%5b	%5d

For example, contrary to documentation, the caret does not need encoding: http://en.wikipedia.org/wiki/^

The apostrophe really applies to sequential use, as it gets parsed as wikimarkup: http://en.wikipedia.org/wiki/12345

The pipe automatically gets encoded: http://en.wikipedia.org/wiki/%7C

---— Gadget850 (Ed) ^talk 21:57, 7 April 2011 (UTC)

"="sign

At the Buddha-nature page, there appears a problem with the = sing: The following url appears as a full url in the reflist, beside the assigned title/name, due to the = sign:

I've tried to fix it, by using %3D, but it doesn't work:

Using {{=}} doesn't work either:

Friendly regards, Joshua Jonathan (talk) 08:05, 7 March 2012 (UTC)

The problem with these examples isn't caused by the equals sign; it's because the title is split over two lines. If you replace that with a space, all is well:

-- John of Reading (talk) 08:15, 7 March 2012 (UTC)

That's it?!? What a joke to miss that one. Thanks!!! Joshua Jonathan (talk) 08:39, 7 March 2012 (UTC)

I think [1] is misleading. Below the table with = and %3d it says "Equals signs only need to be encoded when the url is used as an unnamed template parameter". But most url's are broken if = is replaced by %3d. For example, https://www.google.com/search?q=feral works but https://www.google.com/search?q%3dferal doesn't. In an unnamed parameter neither of them work: https://www.google.com/search?q=feral (the source has a template here) and https://www.google.com/search?q%3dferal both fail. A reliable fix is to replace = by {{=}} as explained at unnamed template parameter. This is an issue with Wikipedia template syntax and not with unsupportred url characters so if we mention it here then I think it should be outside the conversion table. PrimeHunter (talk) 12:50, 7 March 2012 (UTC)

Fair enough. I've reverted to Gadget850's version of this table. -- John of Reading (talk) 12:59, 7 March 2012 (UTC)

Three years on: Note that PrimeHunter's comment in the above thread has been broken by the deletion of Template:Identity. -- John of Reading (talk) 07:07, 8 September 2015 (UTC)

Oh, I have often used Template:Identity to test something, mostly in previews. My use here was removed in [2]. A new version of the broken part of the comment: {{{2}}}(the source has a template here) and https://www.google.com/search?q%3dferal both fail. PrimeHunter (talk) 11:58, 8 September 2015 (UTC)

HTTPS changes

I think that this page and WP:EL need to be updated now that "http" etc. are no longer necessary, and the links' destination (if it is within Wikimedia) will change automatically depending on whether you are viewing the HTTP or the HTTPS version of a Wikimedia site. It Is Me Here ^{t / c} 20:54, 18 December 2011 (UTC)

[scroogle.org test] — Seems like you still need http:// (or https://) in the link code for it to work for me?

I would totally agree if not because Firefox and other browsers are starting to phase out showing HTTP to people as it's as no longer necessary for most people and just useless spam, in fact the only reason most people ever need to see a HTTP:// is because of sites like Wikipedia not parsing links that don't have it! --Mistress Selina Kyle ^{(Α⇔Ω ¦ ⇒✉)} 14:22, 11 February 2012 (UTC)

The MediaWiki software uses CSS to detect the URI scheme and render it as a linked URL; see Help:External link icons for details. ---— Gadget850 (Ed) ^talk 15:25, 11 February 2012 (UTC)

Yeah, but why not have the default be HTTP:// since 99% of links use that, it would add up to a lot of space saved overall when you consider the scale of Wikipedia and make things more pleasant for users to type If you look at most browsers they don't require people to type HTTP:// anymore and in Firefox they actively hide HTTP:// these days because most people just don't need to see it It shouldn't be there at all for common usage really, the only time people need it is when sites like Wikipedia fail to recognise .com/.net links as links! Most forums these days and social networks catch any mention of .whatever and parse it as a link Better for everyone --Mistress Selina Kyle ^{(Α⇔Ω ¦ ⇒✉)} 02:17, 12 February 2012 (UTC)

If you want to change the current scheme, then file a bug. I don't see how your link to Blackle.com is related to this. ---— Gadget850 (Ed) ^talk 12:09, 12 February 2012 (UTC)

Oh, as I said while each one is small, when you consider the scale of Wikipedia all the "http://"s added up, well, I haven't done the maths but I think be a lot of space overall saved? Definitely a lot more convenient for people when browsers are starting to phase out http:// --Mistress Selina Kyle ^{(Α⇔Ω ¦ ⇒✉)} 12:22, 12 February 2012 (UTC)

Don't worry about performance. Browsers are simply hiding the URI scheme— it is still a vital part of the naming structure. ---— Gadget850 (Ed) ^talk 12:34, 12 February 2012 (UTC)

Still it'd be nice for the size (not performance) to get rid of those gazillion http://

But most importantly make it more convenient writing references for editors, because when browsers are starting to delete http:// this is going to be more and more important as people are going to start growing up never seeing an http:// and for good reason, really, we know something .TLD is always going to be http unless otherwise specified, and computers should understand that too - most social network sites do, Wikipedia is still in the 2000s! --Mistress Selina Kyle ^{(Α⇔Ω ¦ ⇒✉)} 12:07, 15 February 2012 (UTC)

http:// is a URI scheme, not a TLD (which would be .com or the like). Again: browsers don't delete the URI scheme, they just hide them. If you have better way to do this, then ask for a feature enhancement. ---— Gadget850 (Ed) ^talk 12:14, 15 February 2012 (UTC)

I know, that's why I said "something .TLD is always going to be http" — there is no . in http://

Well, we don't see DNS being converted into IP addresses either, hiding stuff is good for humans *shrug* --Mistress Selina Kyle ^{(Α⇔Ω ¦ ⇒✉)} 12:26, 15 February 2012 (UTC)

Can someone clarify link behavior with parenthesis?

Wiki-text markup treats a final right parenthesis in special ways. Consider:

• (http://www.example.com) closing parenthesis is NOT part of the link
• (http://www.example.com/parens=()
• (http://www.example.com/parens=())
• http://www.example.com/some/more) closing parenthesis is NOT part of the link.
• http://www.example.com/some(/more)
• http://www.example.com/some(/more)/and/more)
• http://www.example.com/some(/more)/and(/more)

I think the rule is that wikipedia drops the closing parenthesis unless the URL contains a left parenthesis. Can anyone confirm this, or give a pointer to the appropriate documentation? Blevintron (talk) 13:35, 23 April 2012 (UTC)

MediaWiki detects a URL by the URI scheme as noted, so no character before the URI will be included in the link.

No character that requires encoding will be included in the link:

• http://www.example.com>

And some characters are included in the link, and otheres are not. I am not sure why.

• http://www.example.com/parens=(
• http://www.example.com/parens=)
• http://www.example.com/parens=&
• http://www.example.com/parens=!
• http://www.example.com/parens=#
• http://www.example.com/parens=$

---— Gadget850 (Ed) ^talk 13:49, 23 April 2012 (UTC)

Definitive answer: According to includes/parser/Parser.php, function makeFreeExternalLink() (lines 1238--1243),

The following characters are stripped from the end of a free external link: comma ',', semicolon ';', backslash '\', period '.', colon ':', bang '!', question mark '?'.

A right parenthesis ')' is only stripped if the link does not contain a left parenthesis '('

Blevintron (talk) 16:06, 23 April 2012 (UTC)

Thanks. Looks like the encoding chart needs some updates. ---— Gadget850 (Ed) ^talk 19:28, 23 April 2012 (UTC)

No, this is a different concern than encoding. These characters are allowed within URLs unescaped unencoded. My comment relates to how wikipedia chooses to highlight links, not about what characters are allowed in a URL. I think it's incorrect to update the encoding charts.

For Example: http://en.citizendium.org/wiki/Theory_(mathematics) is a valid link, and the parentheses do NOT need to be escaped. Blevintron (talk) 21:57, 23 April 2012 (UTC)

Unsupported?

According to the table at Fixing links with unsupported characters, the characters "," (comma), ";" (semicolon) and "?" (question mark) are unsupported and need to be encoded. But as far as I can see these three work just fine in their original forms. Did something change or is the text just overly cautious?  --Lambiam 19:40, 6 June 2012 (UTC)

Ah, I see what the issue is. They are problematic at the end of a bare url (one not enclosed in square brackets): the parser does not parse them as part of the url. But the same problem also arises with these unlisted characters:

"!", ")", ".", ":" and "\".

 --Lambiam 20:09, 6 June 2012 (UTC)

space not encoded per this help page

For some reason {{urlencode:test test}} (now) gives test+test not test%20test as advertised on this help page. /37.197.83.144 (talk) 14:10, 31 July 2013 (UTC)

The encodings at Help:URL#Fixing links with unsupported characters are needed to get an external URL working properly inside Wikipedia markup. The urlencode parser function has a different purpose, to encode arbitrary text so that it can be part of a URL. -- John of Reading (talk) 14:31, 31 July 2013 (UTC)

I did mean in the context of encoding urls inside Wikipedia markup. That section specifically says "For example, a space must be replaced by %20 (this can be done using the parser function)." So if I want to link to http://test.com?test test then the required url is [3] but using urlencode as suggested we get [4]. So the properties of urlencode have changed and either the help page should be updated or a bug has sneaked in and should be reported. /37.197.83.144 (talk) 15:09, 31 July 2013 (UTC)

Now I see what you are getting at. The job can be done with the urlencode function, but only by using one of its optional keywords: {{urlencode:test test|PATH}} is test%20test. I've added a few words to the help page to make this clearer. -- John of Reading (talk) 15:23, 31 July 2013 (UTC)

Ah. That explains it. Many thanks. /37.197.83.144 (talk) 16:11, 31 July 2013 (UTC)

Open a new page with a hyperlink

It appears that hyperlinks from Wiki replace the page that you are on and the back and forward arrows are used to navigate between hyperlinked locations once they are visited.

Is there a way to specify a hyperlink to launch a new page?

THANKS for your help!!! — Preceding unsigned comment added by 72.37.249.100 (talk) 18:55, 9 January 2015 (UTC)

What browser do you use? In Firefox I right-click on a link and select "Open Link in New Tab". A click with the middle mouse button does this too. -- John of Reading (talk) 19:08, 9 January 2015 (UTC)

(edit conflict) Wikipedia has no way to specify this for others who click a link. Your browser probably has a feature to do it for you, maybe Ctrl+click or Shift+click. Registered users have the option "Open external links in a new tab/window" at Special:Preferences#mw-prefsection-gadgets. PrimeHunter (talk) 19:11, 9 January 2015 (UTC)

Short urls

How can we create a short url of a Wikipedia article for Twitter? Snurl wouldn't cut it.Oceanflynn (talk) 16:39, 6 March 2015 (UTC)

If snurl doesn't cut it then use another service like http://tinyurl.com at URL shortening#URL shortening services. I have just created http://tinyurl.com/7u8sx2y for https://en.wikipedia.org/wiki/URL_shortening as a test. URL shortening services are blacklisted as external links in Wikipedia (for good reasons) so I couldn't save tiny.url as a clickable link. PrimeHunter (talk) 17:52, 6 March 2015 (UTC)

I don't have a Twitter account and don't know what they actually allow but if you still have problems then the place to ask is Wikipedia:Reference desk/Computing. PrimeHunter (talk) 18:01, 6 March 2015 (UTC)

By clicking "Permanent link" in the left pane of a Wikipedia page you can get a link to the latest revision of that page. See Help:Permanent link. If the page is edited later then the link will still go to the version at the time of your click. The url is long but can be shortened. For URL shortening I currently get https://en.wikipedia.org/w/index.php?title=URL_shortening&oldid=650127212. Testing shows it can be reduced to https://en.wikipedia.org/?oldid=650127212. I give no guarantee such url's will continue to work, and it will fail with no trace of the page name if that revision is deleted for some reason. enwp.org is currently a redirect to en.wikipedia.org (also no guarantee this will continue), so http://enwp.org/?oldid=650127212 works now. PrimeHunter (talk) 18:20, 6 March 2015 (UTC)

If you want the current revision of the same page, try http://enwp.org/?curid=3919945 which is shorter by two characters. --Redrose64 (talk) 19:51, 6 March 2015 (UTC)

Nice. I wondered whether the page ID could be used in a link. The ID can be found by clicking "Page information" in the left pane. curid is not documented at Help:URL#URLs of Wikipedia pages but it is at mw:Manual:Parameters to index.php. Newer pages have 8-digit ID's. PrimeHunter (talk) 01:00, 7 March 2015 (UTC)

I'm a little surprised that the slash after the domain can also be dropped, at least in my tests where http://enwp.org?curid=3919945 works, both when clicked and when copy-pasted to the browser address bar. I don't know how stable it is but it worked in all five tested browsers. PrimeHunter (talk) 01:10, 7 March 2015 (UTC)

I have added mention of this to the page.[5] PrimeHunter (talk) 00:27, 9 March 2015 (UTC)

Perhaps it's worth mentioning somewhere that in a Wikipedia query string, the oldid= parameter overrides curid=, as does a diff= with numeric value; and that curid= overrides title= --Redrose64 (talk) 14:44, 9 March 2015 (UTC)

"Dropping http: and https:" section apparently contradicts more recent recommendation

The following recommndation in this help article to use protocol-relative URLs seems to be outdated:

Dropping http: and https:

If you make an external style link using square brackets [...] from a Wikimedia page to other Wikimedia page, including Wikipedia of course, it's better to drop the protocol http: or https:, so that the URL begins with //..., e.g. //en.wikipedia.org/w/index.php?title=Help:URL.

Otherwise, readers are forced to use the specified connection method. If you don't specify the protocol, readers can continue to use the protocol to read that page.

The URL returned by {{SERVER}} magic word begins with //.

• Example: [//en.wikipedia.org/w/index.php?title=Help:URL no protocol]
• Result: no protocol (Read this page both with http and https.)
• Example: [{{SERVER}}/w/index.php?title=Help:URL no protocol]
• Result: no protocol (Read this page both with http and https.)

In contrast to the above, see Help:Link §http: and https:

http: and https:

In mid-2015, Wikipedia and all other Wikimedia sites were changed to use HTTPS to encrypt all traffic. Accessing a URL like http://en.wikipedia.org/wiki/Help:Link will result in the webserver redirecting you to https://en.wikipedia.org/wiki/Help:Link. Therefore, when making an external-style link to an internal page (that is, using single square brackets, or a bare URL), https should be specified to avoid the needless redirect, as in https://en.wikipedia.org/w/index.php?title=Help:Link&action=history.

In the past, when Wikipedia could be accessed via either HTTP or HTTPS, a protocol-relative URL could be used to make an external link (or external-style link to an internal page) which would use http: or https: depending on how the page the link appeared on was accessed, as in [//www.mediawiki.org/wiki/Help:Links]. However, as all Wikimedia sites now require HTTPS, this linking style is obsolete and should no longer be used. http: or https: should be explicitly specified as appropriate for the target site (preferring https:, where available).

Should it therefore be updated here to match? That said, the explanation in the latter blockquote is actually wrong at a technical level; there is not a redirection happening with the protocol-relative URL for fellow Wikimedia pages, as it now will always be coming from an HTTPS Wikipedia page and causing the user to navigate to another HTTPS Wikimedia page; "https://" and "//" will always result in the exact same request, now. (Well, at least as long as this is happening from a Wikimedia-hosted site. That is, the two would give different results when navigating from one of those copies of Wikipedia that exist, if it's on an HTTP site. Also, if a user saves a page locally, the browser will futilely try to load the linked page with the "file://" protocol, unless the user's browser automatically changed URLs to fully qualified ones when saving the originating HTML file.) —Undomelin (talk) 23:03, 24 January 2019 (UTC)

underscores as spaces

I couldn't find mentioned here how browsers (at least mine) accept the _ character in place of spaces. Let's take an example - our Gravity (2013 film) article as external URLs:

• [6] encoded with underscores
• [7] encoded with percent-twenties

Assuming both work in general, please update the documentation. CapnZapp (talk) 18:45, 4 February 2021 (UTC)

Your browser treats %20 the same as a space, and similarly treats %5F the same as an underscore. It treats spaces and underscores differently (whether percent-encoded or not); it is the MediaWiki software that treats them as equivalent. --Redrose64 🌹 (talk) 19:44, 4 February 2021 (UTC)

Thank you but I'm asking why our Help page only talks about %20 and not underscores. (The underscore is mentioned exactly once, where its function is taken for granted). We should not treat our readers as browser experts and wiki beginners at the same time. Since you can't use URLs on Wiki without the use of a browser, the distinction "it's your browser that does it, not MediaWiki" is irrelevant. Or, perhaps not irrelevant - if the distinction is important it can be mentioned but the main point is that we can't just explain %20's but not underscores... CapnZapp (talk) 22:41, 4 February 2021 (UTC)