APEX validations: Email address

In this (and the next) blog posts I will demonstrate different techniques for validating user input in Oracle APEX. I bet you needed to validate an item – for example if the user has entered a valid e-mail address, a valid number, a valid name or phone number, a valid license plate, personal id number – you name it. Read how you can achieve that using the APEX built-in functionalities, using third party Javascript libraries or simply by using CSS and HTML attributes.

After I demonstrate all the options you can check the chart with pros and cons and decide for yourself which type of validation fits your application best. What I find best is combining several of them to achieve the best in terms of speed, functionality and user experience.

So the possible options to validate an e-mail covered in this post are:

🔸 Using Validation on page submit
🔸 Defining the page item as Text Field type and e-mail subtype
🔸 Using the pattern HTML attribute for your input
🔸 Using a Dynamic Action
🔸 Using the validator.js JavaScript library

🎁 As a bonus I will show you how to add some fancy animation when user enters invalid e-mail.

See the E-mail validations demo in action here: https://apex.oracle.com/pls/apex/r/gamma_dev/demo/email-validation

Method 1 – Validation on Page Submit

The most popular and widely used method – it’s the good old item validation. The validation displays some error message in case the user input in a Text Field is not a valid email address. It is triggered on page submit. Here you could use regular expressions or any other PL/SQL functions to check the provided string.


  • Easy to implement
  • Prevents user from submitting incorrect data
  • Allows using PL/SQL for validation (Regular Expressions and Pattern Matching, custom functions, etc.)


  • Requires full page submit
  • User can't see the error before page is submitted
select 1
from dual
where not regexp_like (nvl(:P21_EMAIL_SUBMIT,'n/a'), '^[A-Za-z]+[A-Za-z0-9.]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,4}$')

Method 2 – Using the Text Field “E-Mail” subtype

Oracle has made it easy for us to validate some of the most popular types of strings that users need. You can select between number, email, phone number, search, URL and so on. Selecting the E-Mail subtype would trigger an auto validation on beach submit. It will also tell you the exact error you have in your text such as missed @. The Subtype can be found under Settings for the items of type Text Field.


  • Easy to implement
  • Prevents user from submitting incorrect data
  • Shows a detailed error, including a text and an icon next to the item
  • No need to define additional validation (like in previous method)


  • Requires full page submit
  • User can't see the error before page is submitted
  • Doesn't allow using Regular Expressions and custom code to validate the input
  • Validation is not very accurate - for example it will allow a string like invalid@email

Method 3 – HTML pattern attribute

A method that most people probably haven’t tried. It allows validation of all kinds of inputs using a Regular Expression and the special pattern attribute. In the case of validating E-mails there is another attribute – multiple, which allows validating multiple emails which are coma separated.

 <input type="email" pattern="[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$">

The user input will be checked for the above pattern. It will immediately alert the user if the string is not a valid email and will not allow page submit.

 <input type="email" multiple>

The multiple attribute will allow validation of multiple email addresses, separated by a comma. For example email1@multiple.eml,email2@multiple.eml


  • Easy to implement
  • Prevents user from submitting incorrect data
  • Shows a detailed error, including a text and an icon next to the item
  • No need to define additional validation (like in previous methods)
  • Allows validating multiple emails
  • Validation is as accurate as your Regular Expression - in other words, it could be very accurate


  • Requires full page submit
  • User can't see the error before page is submitted

BONUS – Make Method 2 & 3 user friendly using just one CSS property

For the previous two methods we said that you need to submit your page before you can see the error. Yes and No. Yes, you need to submit before you can see the detailed errors.

You need to submit the page in order to see the detailed error message.

And No, with a pinch of CSS magic you can alert the users as they type that their string is invalid email. To do that, assign a custom class to each Text Field in Advanced > CSS Classes. I have named mine email_validate. Very important here is the input:invalid CSS style. It basically allows us to assigns different CSS style as soon as the input has incorrect data.

input.email_validate:invalid {
      animation: shake 0.2s ease-in-out 0s 3;
      box-shadow: 0 0 0.3em 0.05px red;

@keyframes shake {
      0% { margin-left: 0rem; }
      25% { margin-left: 0.5rem; }
      75% { margin-left: -0.5rem; }
      100% { margin-left: 0rem; }
Adding the email_validate CSS class, will make your input field shake as soon as the user enters an invalid email and will get back to normal when the text is a valid email.

Method 4 & 5 – Dynamic Action + Javascript

I have decided to combine these two methods in one. You could have a Dynamic Action that does the Text Field validation using Server Side PL/SQL (Regular Expression Pattern Matching, Substringing, Custom functions, etc.) or using Client Side Javascript (validator.js). In this case, we will have a Dynamic Action, triggered on “Lose Focus” event of the Text Field. This will allow for the validation to be triggered only when the user has stopped typing and is switching to other element on the page.

To include the Validator Javascript library, you can use the following URL (added to the JavaScript File URLs of your APEX page):



  • Triggered only when needed
  • Uses Dynamic Action, no full page submit needed
  • Allows using fine grained validations using both PL/SQL and Javascript code


  • More steps needed to implement
  • Requires additional JS library
  • Requires additional process "Before Page Submit" to trigger the same check in order to prevent user from sending invalid email to the database
if (validator.isEmail(apex.item("P21_EMAIL_DA").getValue())) {
   // Displays a page-level success message ‘Valid email!’.
   apex.message.showPageSuccess("Yes, it is a valid email!");
} else {
   // Now show new errors
         type:       "error",
         location:   "page",
         message:    "Not a valid email address!",
         unsafe:     false

What did I chose?

As you can see, there are PROS and CONS in each of the above methods. However, I think that several are the most important points that you have to handle, everything else is a mater of choice:

  • Validation should be as good as possible. That’s why I would use either custom PL/SQL (or HTML pattern Regular Expression) … or external library for that.
  • Limit the calls to the database and do as much as possible on the Client Side – so here my favourite is the pattern HTML attribute and the Dynamic Actions
  • Make it user friendly, that’s why I will probably go with the shake CSS effect to notify the users as they type (or at least as they leave the input)
  • Do not allow invalid strings to get inserted into the database – always make sure your method of choice is secured against that.

Check the demo again here:

Liked that post? Follow me on Twitter and LinkedIn!

Follow the Twitter discussion. There are some very interesting points raised there!

@plamen_9 on Twitter

Plamen Mushkov on LinkedIn

2 thoughts on “APEX validations: Email address

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s