Everything we visit on the web has a URL, so what exactly do all the parts of a URL designate in order to get us to where we want to go?
Where It All Starts
Things start with a , of which there are many. To become an official registry, you need to be accredited by ICANN. Domain registries are various databases that store things like who owns which domains and what IP addresses are tied to them. IP addresses are like your street address, they are the address to the computer, or “container” in a computer, that your website is hosted on.
The process goes...
Purchase a domain name from a domain registry Assign the IP address of the computer your website is located to the domain name Visit your website in any browser
Standard Parts of Every URL
We type URLs all the time and we know that some parts are auto-populated for us, to the point that we don’t even notice these parts most of the time. So what function do these parts serve?
https:// - Hyper Text Transfer Protocol - Every URL starts out with either http:// or https://. This is the protocol the browser uses to transfer requests and data that are the webpages we view. Other protocols are used for other types of digitally transferred information, like email, but if it’s something to be viewed in a browser, it will go through http. The s that you see in https:// means that URL includes a secure certificate and that the information is encrypted while being transferred between the server and your computer. Almost every website will run with https now-a-days.
TLD - Top Level Domain (.com, .org, .io, etc) - This is where things start and these are what we know as the “domain ending”. Examples are .com, .org, .io, etc. Each top level domain is controlled by a registry, so the browser will look for the TLD and then route the request appropriately.
Domain Name - This includes the TLD and is exactly what you think of when you type in a website. Coda’s domain name is . Sub Domain - A website can be split up into sub domains that can be included in the URL for a more direct link. Coda uses sub domains for things like our help docs, . A sub domain is either before the main domain name and separated by a dot or it can be written in a more folder like notation with a slash and after the main domain name, . The sub domains can continue just like a nested folder structure continuing to be separated by a forward slash.
Coda parts of a URL
The core parts of this example URL are:
Sub Domain → /d - All docs live in this sub domain. This allows our engineers and security team to designate certain rules and server protections to all docs within this sub domain.
After the /d, we see the...
Doc Title - “Coda-URLs-Explained” - This is the title of the doc converted to have no spaces and no special characters, which would break a URL. This part can change and our Coda system actually doesn’t rely on this part of the URL to find a doc. Doc Prefix - “_d” - This is a prefix used to designate that a doc ID is following. Doc ID - “0CodpUjxQa” - This is the doc ID that is used throughout the Coda system to identify the exact doc you are interested in. This is a unique value and what our system used to find the exact doc. Relying on this ID to find the doc means the doc title can change, but the correct doc will still always be found.
But wait, there’s more. This ID thing works so well that we also used it for pages, tables, and even rows. Here’s a longer URL that lets us go directly to a specific part of the doc.
The part in italics is what we’ve already been over, then we see a / which separates the doc title part from the next part. This next part is the Page.
For the Page, we see a similar pattern to how the doc is designated. The Page parts are as follows:
Page Title - “Example-Setup” Page Prefix - “_su” - This is designated with a _s because pages used to be called sections. And the u stands for “shortened URL” because we only use 3 characters from the Page ID, not the whole thing. Page ID - “ObM” - the last 3 characters of the full Page ID.
Now we run into a # which is similar to a / in that it points to something more specific, but it’s used when the part being pointed to is within the same page you are currently viewing. That means when you see a /, the page will need to reload to display, like switching pages, but with a # the URL is moving your cursor to another part of the page you are already on.
After this #, we see the same pattern we’ve been using, only this time it’s used to designate a table. The table parts of the URL are as follows:
Now we see one last part and it’s separated by a /. This part breaks the pattern a little bit because we don’t include a title. This is the row ID. When using a URL to this specificity, you’ll notice that exact row highlighted when you first visit it. The row parts of the URL are as follows:
So written out to show the pattern, we have...
Embed and Version History URL’s
Coda has two other types of URL’s that we use for two specific scenarios, embeds and version history.
When sharing a doc and embedding it, we will see /embed/ instead of /d/. If you open the share dialog for any doc and click on the Embed tab, you will see the following:
We also use something similar when viewing version history.
A fun experiment is to think through what you would need to edit or replace in an embed link or a revision link to get the link for the main doc.
Parameters are variables that let us take an action on a page or have the page show in a different manner then how it would show with just the basic URL items we discussed above. Coda has a few different places where we use parameters and knowing these tricks can help out when you want to show off with some Coda pro moves. Some examples that we’ll see below are forcing a row to show in a modal popup, forcing a shared doc into play mode, auto-filling form fields with a set value, and a few others.
We’ve seen that various characters each serve a specific purpose in a URL, / separates sub domains and # anchors to a specific point on a page. Parameters have their own characters so the browser knows where to find them and what to do with them.
Parameter characters are as follows:
? - A question mark designates the start of URL parameters. Sometimes there is only one parameter and sometimes there is a list of parameters. & - An ampersand designates additional parameters in a list. If you only have one parameter, you’ll only need the question mark, but you’ll need to use an ampersand to link any additional parameters after that first one.
Let’s take the last URL example we were working with above and add a parameter to it.
From what we’ve learned so far, this URL will take us to our Coda doc, go to the specific page, move us to the correct table on the page, and highlight the specific row. The added parameter of “?modal=true” will display that row in the popup modal style for easier viewing.
The breakdown of the parameter is as follows:
Here is an example of listing two variables in a URL. Notice the placement of the ? and the &.
Common Coda URL parameters
view=modal - Shows a row in the popup modal style view=full - Shows a row in full screen style viewMode=embedplay - Places the doc in “Play” mode so changes are not saved but visitors can still use it to experiment and see how things work. This is great for sharing how-to examples or for docs that want to offer online calculators. viewMode=publishedEdit - Displays the doc in published mode, but with the regular doc URL. hideSections=true - This will hide the page list on the left hand side of the doc by default. This is helpful when you want to draw attention to the content on a specific page.
Coda Forms are a great component and work in an interesting way. In order for us to link to a form without linking to the entire doc, helpful when you don’t want to share the data you’re collecting, we use a separate URL to display just the form itself. This URL has a very similar pattern to what we see in the main Coda URL’s.
A form has an ID all its own just like a doc. We can see above that the /d/ from a doc URL is replaced with /form/ and then the form title, doc prefix, and form ID follow.
Now let’s say we have some columns in our form table that we would like to have pre-filled for the end user.
We start the list of parameters with a ? and then list the items to auto-fill with the pattern Column=Value.
If we have more than one column to fill, we use an & between each column/value pair, Column=Value&Column=Value.
And if we have a multiple option column, we can separate those values with a , like this Column=Value&Column=Value,Value.
Certain characters in URL’s are reserved for various functions, like /, #, ?, and &. Other characters can cause issues as well, so we need to encode those characters to be readable by the browser as a text value instead of the reserved value. For this, we use .
An excerpt from W3Schools
URL encoding converts characters into a format that can be transmitted over the Internet. URLs can only be sent over the Internet using the . Since URLs often contain characters outside the ASCII set, the URL has to be converted into a valid ASCII format. URL encoding replaces unsafe ASCII characters with a "%" followed by two hexadecimal digits. URLs cannot contain spaces. URL encoding normally replaces a space with a plus (+) sign or with %20.
The good news is you can actually use Coda to encode your URL’s. We have an . This will make all the necessary character substitutions and you can plug the result right into your URL.
https://coda.io/form/Form-Title_d0CodpUjxQa?Column 1=Value 1
Column 1 → Column%201 and Value 1 → Value%201
So our final URL will be:
If you made it this far, it’s safe to say you’re now a URL Expert. You’ll also start to notice patterns, hints, and tricks in other systems which you can make use of within Coda formulas.
Do you use the Gmail pack? If so, you can retrieve the Id of any email synced and create a link that takes you to that email in your inbox.