Form Handling in Flask

Forms are an essential part of any web application but unfortunately working with them is quite difficult. It all starts with the client, first, you have to validate the data on client side, then on the server. If that’s not enough, you have take care of all the security concerns like CSRF, XSS, SQL Injection and so on. All in all, that’s a lot of work. Fortunately, we have an excellent library called WTForms to do the heavy lifting for us. Before we learn more about WTForms, the following section gives you a little tour on how you can go about handling forms in Flask without using any library or package.

Form Handling – The Hard Way

Create a new template named login.html with the following code:


Next, add the following code just after the books() view function in


Notice the methods argument passed to the route() decorator. By default, the request handler is only called when the request.method is either GET or HEAD. This can be changed by passing list of allowed HTTP methods to the methods keyword argument. From now on, the login() view function
will be called only when the request to /login/ is made using GET, POST or HEAD method. Trying to access /login/ URL using any other method will result in HTTP 405 Method Not Allowed error.

In previous lessons, we have discussed that the request object provides information about the current web request. The data submitted via the form is stored in the form attribute of the request object. The request.form is a dictionary like immutable object known as ImmutableMultiDict.

Start the server and visit http://localhost:5000/login/. You should see a form like this.

The page is requested using the GET request, so the code inside the if block in login() view function is skipped.

Submit the form without entering anything and you should see a page like this:

This time the page was submitted using the POST method, so the code inside the if block is executed. Inside the if body we access username and password and set the value of message variable accordingly. Since we submitted an empty form, an error message is displayed.

Fill the form with correct username and password and hit enter. You should be greeted with "Correct username and password" message as follows:

That’s how we handle forms in Flask. Let’s now shift our attention to the WTForms package.


WTForms is a powerful framework-agnostic (framework independent) library written in Python. It allows us to generate HTML forms, validate forms, pre-populate form with data (useful for editing) and so on. In addition to that it also provides CSRF protection. To install WTForms we use Flask-WTF.

Flask-WTF is a Flask Extension which integrates Flask with WTForms. Flask-WTF also provides some additional features like File Uploads, reCAPTCHA, internationalization (i18n) and so on. To install Flask-WTF enter the following command.

Creating Form class

We start by defining our forms as Python classes. Every form class must extend the FlaskForm class of the flask_wtf package. The FlaskForm is a wrapper containing some useful methods around the original wtform.Form class, which is the base class for creating forms. Inside the form class, we define form fields as class variables. Form fields are defined by creating an object associated with the field type. The wtform package provides several classes which represent form fields like StringField, PasswordField, SelectField, TextAreaField, SubmitField and so on.

Create a new file inside flask_app dictionary and add the following code to it.


Here we have defined a form class ContactForm which contains four form fields: name, email, message and submit. These variables will be used to render the form fields as well as set and retrieve data to and from the fields. The form is created using two StringField‘s, a TextAreaField and a SubmitField. Everytime we create a field object, we pass some arguments to its constructor function. The first argument is a string containing the label, that will displayed inside the <label> tag when the form field is rendered. The second optional argument is a list of validators passed to the constructor function as keyword arguments. The validators are functions or classes which determines whether the data in the field is valid or not. We can apply more that one validator to a field by separating them by a comma (,). The wtforms.validators module provides some basic validators but we can also create our own validators. In this form, we are using two built-in validators DataRequired and Email.

DataRequired: It ensures that the user must enter some data in the field.

Email: It checks whether the entered data is a valid email address or not.

The data in the field will not be accepted until all the validators applied on it are satisfied.

Note: We have barely scratched the surface of form fields and validators, to view the full list visit

Setting up the Secret Key

By default, Flask-WTF prevents all forms from CSRF attacks. It does this by embedding a token in a hidden <input> element inside the form. The token is then used to verify the authenticity of the request. Before Flask-WTF can generate csrf token, we have to add a secret key. Open and set the secret key as follows:


Here we are using the config attribute of the Flask object. The config attribute works just like a dictionary and it is used to place configuration options for Flask and Flask extensions but you can also place your own configuration if you want to.

The secret key should be a long, hard to guess string. The use of SECRET_KEY is not just limited to creating CSRF tokens, it is used by Flask and many other extensions. The secret key should be kept secret. Rather than storing the secret key in the application, a much better approach would be to store it in an environment variable. We will learn how to do this in later chapters.

Forms in the Console

Open Python shell by entering the following command:

This will start Python shell inside the application context.

Now import ContactForm class and instantiate a new form object by passing form data to it.

Notice that we are passing form data as MultiDict object, because the constructor function of wtforms.Form class accepts an argument of type MultiDict. If the form data is not specified while instantiating form object and the form is submitted using POST request, wtforms.Form will use the data from the request.form attribute. Recall that request.form returns an object of type ImmutableMultiDict which is same as MultiDict object but it is immutable.

The validate() method of the form object validates the form. On success, it returns True, otherwise False.

Our form failed to validate because we haven’t provided any data to the required message field while creating the form object. We can access form errors using the errors attribute of the form object:

Notice that in addition to error message for the message field, the output also contains error message for the missing csrf token. This is because we don’t have an actual POST request with csrf token in the form data.

We can turn off CSRF protection on the form by passing csrf_enabled=False while instantiating form class. Here is an example:

As expected, now we are only getting error for the missing message field. Let’s create another form object but this time we will supply valid data to all the form fields.

The form validation succeeds this time.

Our next logical step would be to render the form which is discussed next.

Rendering Form

There are two ways to render form fields:

  1.  Render fields one by one.
  2. Render fields using a for loop.

Rendering fields one by one

In the templates, once we have access to form instance, we can use the field names to render fields, label, and errors as follows:

Let’s test this inside the console:

Here we have instantiated the form object without any request data, this is usually the case when the form is displayed for the first time using the GET request.

Since the form is displayed for the first time, none of its fields will have any validation errors. The following code demonstrates this:

Instead of displaying validation errors per field you can use form.errors to access all the validation errors associated with the form. The forms.errors is commonly used to display validation errors at the top of the form.

While rendering fields and labels, we can also supply additional keyword arguments which will be injected in the HTML as key value pairs. For example:

Now suppose our form has been submitted. Let’ try rendering fields this time and see what happens.

Notice that the value attribute of name and email field is filled with the data. However, the <textarea> element for the message field is empty since we didn’t supply any data to it. We can access the validation error for the message field as follows:

Alternatively, you can also use form.errors to loop through all the validation errors at once.

Notice that we are getting missing csrf token error because the request the was submitted without csrf token. We can render the csrf field just like a normal field as follows:

Rendering field one by one can be cumbersome if you have quite a few form fields. For such cases, you can use for loop to render the fields.

Rendering fields using loop

The following shell session demonstrates how we can render fields using the for loop.

It is important to note that no matter which method you use you have to manually add <form> tag to wrap the form fields.

Now we know how to create, validate and render forms. Let’s use this knowledge to create some real forms.

Start by creating a new template contact.html with the following code:


The only missing piece of the puzzle is the view function which we will create next.

Handing Form Submission

Open and add the following code just after the login() view function.


In line 7, we are creating a form object. In line 8, we are are checking the return value of validate_on_submit() method to execute some code inside the body of the if statement.

Why we are using validate_on_submit() instead of validate() just like we did in the console ?

The validate() method simply checks whether the form data is valid or not, it doesn’t check whether the request is submitted using the POST method or not. That means if use we validate() method then a GET request to /contact/ would trigger the form validation and users will see validation errors in the form. In general, we trigger validation routines only when the data is submitted using the POST request. The validate_on_submit() method returns True when the form is submitted using the POST request and data is valid. Otherwise False. The validate_on_submit() method internally calls the validate() method. Also, notice that we are not passing any data while instantiating the form object because when the form is submitted using the POST request WTForms reads the form data from the request.form attribute.

The form fields defined in the form class becomes attribute to the form object. To access field data we use the data attribute of the form field:

To access all the form data at once use the data attribute of the form object:

When you visit URL /contact/ using the GET request, the validate_on_submit() method returns False, the code inside the if body is skipped and the user is displayed an empty HTML form.

When the form is submitted using the POST request, the validate_on_submit() returns True assuming the data is valid. The print() calls inside the if body prints the data entered by the user and the redirect() function redirects the user to the /contact/ page. On the other hand if validate_on_submit() returns False execution of statements inside the if body is skipped and form with validation errors is displayed.

Start the server, if not already running and visit http://localhost:5000/contact/. You should see Contact Form like this:

Without entering anything hit submit and you will be displayed validation errors like this:

Enter some data in Name and Message field and invalid data in the Email field and submit the form again.

Notice that all the fields still contains data from the previous request.

Enter a valid email in the Email field and hit submit. This time our validation will succeed and inside the shell running the server you should see output like this:

After displaying submitted data in the shell the view function will redirect the user to /contact/ URL again. At this point, you should see an empty form without any validation errors as if you visited /contact/ URL using the GET request for the first time.

It is good practice to display some feedback to the user after successful form submission. In Flask, we create such feedback using flash messages which is discussed next.

Flash Messages

Flash messages is another one of those functions which depend upon the secret key. The secret key is necessary because behind the scenes flash messages are stored in the sessions. We will learn what sessions are and how to use them in depth in lesson Session in Flask. Since we have already set the secret key, we are ready to go.

To flash messages, we use flash() function from the flask package. The flash() function accepts two arguments, the message to flash and an optional category. The category indicates the type of message such as _success_, _error_, _warning_ etc. The category can be used in the template to determine the type of alert message to display.

Open and add flash("Message Received", "success") just before the redirect() call in the contact() view function as follows:


The message set by the flash() function will only be available for the subsequent request and then it will be deleted.

We are now setting the flash message, to display it, we have to modify our template too.

Open contact.html and modify the file as follows:


Jinja provides a function called get_flashed_messages() which returns a list of pending flash messages without the category. To get the flash message along with the category pass with_categories=True while calling get_flashed_messages(). When with_categories is set to True, get_flashed_messages() returns a list of tuples of the form (category, message).

After making these changes visit http://localhost:5000/contact/ again. Fill the form and hit submit. This time you should get a success message at top of the form as follows:

3 thoughts on “Form Handling in Flask

  1. I think this is among the most significant info for me. And i
    am glad reading your article. But should remark on some general things, The website style is wonderful, the articles is really great :
    D. Good job, cheers

  2. Hi, I would like to know how we get the flask’sessions active user name? For a login page i need to know the active user of that particular session.

Leave a Comment

%d bloggers like this: