Using Forms in Email: Method or Madness?

Originally published at:

So, the first question is: why would to want to use forms in email?

It’s a good one since I personally don't believe there currently is a good reason to embed a form in an e-mail. Users will still need to submit the form to a web page, so there is really no extra convenience in terms of usability.

In addition, you now lost the ability to perform client-side validation on email forms because JavaScript and HTML5 form constraints are inconsistent.

There may be usecases where adding a form to an email is raised as an option – maybe to increase the impact of a message or to stimulate immediate user interaction (for example, to ask for a comment).

In cases like this we are not talking about something that can be solved with a simple web link.

You may have seen something like this:

A radio button set with three faces - happy, sad and passive.

The safest and simplest way to do that is to add a link to each smile with a specific variable to record the user choice.

But what about something like this one?

A panel with Three faces - smile, passive & sad

Obviously you can't use a unique link to save both satisfaction and comment, so, if you decide you don't want to send users to a web page, you'll need to add a form to your email.

I searched the web for information on email form compatibility, but only found a handful of (mostly old) articles on the subject:

On the positive side, things have not changed very much from what they describe, but out of curiosity, I decided to run some of my own tests with a simple form on some email clients.

The Form

I built a very simple mail: it contains a sample of main form elements:

  • a text input
  • two radio buttons
  • a checkbox
  • a select
  • a textarea.

For each of them I provided a default value and, in addition, the input text field had a required attribute.

I ran two test with HTML5 and XHTML 1 strict doctypes. Both versions have passed the W3C validator.

Here is the HTML5 code I used:

< !DOCTYPE html>
<html lang="en">
    <meta charset="utf-8"/>
    <title>Email form test</title>
    <h1>Email form test</h1>

    <form id="form1" action="result_page.html" method="get">
        <div style="margin-bottom:10px">
            <label for="text">Text field</label><br />
            <input required type="text" id="text" name="text" value="Some text"/>

        <div style="margin-bottom:10px">
            <input type="radio" id="radio1" name="radio" value="radio 1 value" checked/>
            <label for="radio1">Radio button 1</label><br />
            <input type="radio" id="radio2" name="radio" value="radio 2 value"/>
            <label for="radio2">Radio button 2</label>

        <div style="margin-bottom:10px">
            <input type="checkbox" id="checkbox" name="checkbox" value="checkbox value" checked/>
            <label for="checkbox">Checkbox</label>

        <div style="margin-bottom:10px">
            <label for="select">Select</label><br />
            <select id="select" name="select">
                <option value="select option 1">Select option 1</option>
                <option value="select option 2" selected>Select option 2</option>
                <option value="select option 3">Select option 3</option>

        <div style="margin-bottom:10px">
            <label for="textarea">Textarea</label><br />
            <textarea cols="60" rows="5" name="textarea" id="textarea">More text</textarea>

            <button type="submit" name="Submit">Submit</button>

Here is how it appears in Chrome (mac):

Chrome rendering

The XHTML version is the same with a handful of some language-specific differences.

Checked clients

I've tried both versions of the form on these clients:


  • Apple Mail (v.8.2)
  • Thunderbird (OSX, v.31.4)
  • Windows Live Mail 2012 (Windows 7)
  • Outlook 2013 (Windows 7)


  • iPad Mail (IOS 8.2)
  • Gmail App on iPad
  • Yahoo Mail on iPad
  • Outlook for IOS
  • Gmail App on Android (v.5.0.1)
  • Native E-Mail App on Android 4.4.4
  • Yahoo Mail on Android (v.4.8.4)
  • Gmail Inbox Android (v.1.2)


  • Gmail
  • Yahoo Mail

Webmail versions have been tested using Firefox 35 on OSX.

Continue reading this article on SitePoint

From a security perspective forms in an email are something to definitely avoid - even if your testing had given different results and shown that they could actually be made to work across all of those email clients.

There would be no way to tell which spammer you were transmitting the form to (unlike links to web pages where at least some browsers will give you a some idea of where they really go if you hover over them).

If using forms in emails actually worked then all spam emails would include forms to collect information from anyone who is misled into opening it and filling out the form. Not only would the spammer confirm their email address (as they can if the person clicks a link in their spam or allows remore images) but they also get the information the person typed into their form.

Those email clients that refuse to display the form are far more secure than those that simply displaya dialog telling the person they can cancel submitting the form.


Agreed. Currently it's arguably easier to obfuscate where a link is really going on a webpage than it is in email. I can code a webpage link to, but overwrite it with '' as you click it, as long as JS is available. In email I can't think of a way of hiding a bad link from hover.

But a form would allow you to hide that URL destination away from anyone not viewing and understanding the source.

I wonder why browser makers have never tried to feed the destination URLs from forum submit buttons back to the status bar?

It's so simple just to provide a link to an online form that it seems pointless to fret over how forms can be placed in emails. Of course, clients and their whims are always the fly in the ointment. It's good to have articles like this to point them to, all the same!

I often take my lead on this sort of thing from the major emailing services themselves, and even they don't like the idea much. See this, for example:

FYI: The reason microsoft uses Word to render html in outlook is very simple: In the earlier days, IE was used. So everything worked perfectly well. But then came along politicians (EU) who prohibited this. The reason IE is not allowed to be used as rendering engine in Outlook is that IE is delivered as part of Windows and not as part of Office. And Outlook is part of office.

It's the same reason we now have Windows versions without Windows Media player (atleast in the EU).

That's not a reason to use Word as a rendering engine, though. Why not build something that makes the web work properly? It's appalling what they've done to email.

In my opinion emails are a very good tool for communication and marketing, and could be better if the clients were improved with greater adherence to standards and more attention to the security issues rightly reported in previous posts.
Right now, forms in email are a very bad choice but, I think, it could be possible make them work fine.

About Outlook.I think that the problem arises from the choice, more than legitimate, to integrate it with the Office family. Unfortunately, as we have seen many times before, the "rest of the world" was not taken into account ...

To me, emails are NOT web pages. Text and a few small weight non-beacon images are fine. But if a page is wanted, link to it. Please


Yes, and that's the problem. MS should have learned during the browser wars that doing your own, proprietary thing is ultimately doomed to fail, and is bad for the community as a whole, too. Sadly, the message still isn't getting through to some parts of the company. frowning

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.