THE SERIALIZABLE Isolation level is one kind of extended version of the REPEATABLE READ Isolation level.
Now with the SERIALIZABLE Isolation level, you cannot modify the data while another transaction is reading the same data.

For SELECT-only transactions, use the SERIALIZABLE isolation level when you do not want to see the other transaction commits during your transaction.

For UPDATE and DELETE transactions, SERIALIZABLE isolation prevents concurrent modification of the same data row; it should therefore be used with caution.

Create a table with few sample records:

CREATE TABLE tbl_Employee
(
	EmpID INTEGER
	,EmpName VARCHAR(50)
);
 
INSERT INTO tbl_Employee
VALUES 
(1,'Anvesh'),(2,'Neevan')
,(3,'Roy'),(4,'Martin');

Execute in this current session. e.g. Session – A:

BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;  

UPDATE tbl_Employee SET EmpName ='Varlin' WHERE EmpID=4;

SELECT *FROM tbl_Employee;

 empid | empname
-------+---------
     1 | Anvesh
     2 | Neevan
     3 | Roy
     4 | Varlin

Execute in anohter session, e.g. Session – B:

UPDATE tbl_Employee SET EmpName ='Loother' WHERE EmpID=3;

SELECT *FROM tbl_Employee;

 empid | empname
-------+---------
     1 | Anvesh
     2 | Neevan
     4 | Varlin
     3 | Loother

Execute in anohter session, e.g. Session – C:

INSERT INTO tbl_Employee
VALUES (5,'Mahi');

SELECT *FROM tbl_Employee;

 empid | empname
-------+---------
     1 | Anvesh
     2 | Neevan
     4 | Martin
     3 | Loother
     5 | Mahi

Execute COMMIT on first Current Session – A:

--Nothing happen to this Query and Data is as it is. 

SELECT *FROM tbl_Employee; 

 empid | empname
-------+---------
     1 | Anvesh
     2 | Neevan
     3 | Roy
     4 | Varlin

-- Now Execute COMMIT:
COMMIT TRANSACTION;

The REPEATABLE READ allows you to read the same data repeatedly and it makes sure that any transaction cannot update this data until you complete your reading.
If you are selecting the same row twice in a transaction, you will get the same results both the times.

If someone is modifying the data, you cannot even read those data until they complete the update.
This is very similar to READ COMMITTED Isolation level.

The REPEATABLE READ issues the shared locks on all statements which are in the transaction.
The shared locks do not release lock at each statement level, but it applies at the transaction level.

The REPEATABLE READ does not stop insertion of newer records so when we are reading data with this isolation level, there is a chance to get Phantom or Dirty Reads.

For example,
You are selecting range data between ID 200 and ID 500, and in this range, we have one free ID which is 394.

Now the user is going to insert a new record with ID 394, and you are selecting data from multiple sources, so there are chances to get different results for your both SELECT statements.

Like one data set with ID 394 and other data set may be without ID 394.

Now, test the REPEATABLE READ isolation level:

First, create a table with sample data:

CREATE TABLE tbl_Employee
(
	EmpID INTEGER
	,EmpName VARCHAR(50)
)
GO
 
INSERT INTO tbl_Employee
VALUES 
(1,'Anvesh'),(2,'Neevan')
,(3,'Roy'),(4,'Martin')
GO

Open a new query window or session and executing this script:

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ  

BEGIN TRAN  

SELECT *FROM tbl_Employee
WAITFOR DELAY '00:00:15'
SELECT *FROM tbl_Employee

ROLLBACK

During the delay of 15 seconds, Open a new query window or session and try to UPDATE this table:

UPDATE tbl_Employee SET EmpName ='Loother' WHERE EmpID=4

Now, you can not UPDATE the data because it used by another session.